[MaxGhenis]

Summary

From 2021 to 2023, Montana let married couples file separately on the same form (filing status 2a, columns A and B). mt_medical_expense_deduction_indiv models each column's medical deduction. It read person("other_medical_expenses") for each spouse. other_medical_expenses sits on the person cared for, including amounts other household members paid on that person's behalf (CPS ASEC PMED_VAL; #10270, still open, documents this on the variable). So a dependent's medical bills reached neither column. The joint variant counts every member's.

This PR:

• adds mt_medical_and_dental_expenses_indiv, line 1a of the Itemized Deductions Schedule in each column: each spouse's own other medical expenses plus their share of every dependent's; an unmarried filer's column holds all of them;
• adds mt_dependent_medical_expense_head_share, the head's share of the dependents' bills, chosen to minimize the couple's Montana tax over a small closed-form candidate set;
• makes mt_tax_unit_itemizes choose the separate path's election (both itemize or both take the standard deduction) by the couple's tax, not by summed deductions.

mt_medical_expense_deduction_indiv floors line 1a at 7.5% of the column's Montana AGI. Lines 2 and 3 (premiums) don't change.

Law, and the choice it leaves

• Line 1 (2022 Form 2 instructions, PDF p. 32): "Enter your medical expenses paid in 2022 … the same medical and dental expenses that are allowed under the Internal Revenue Code." IRC 213(a) covers medical care "of the taxpayer, his spouse, or a dependent".
• Allocation between columns (2022 Form 2 instructions, PDF p. 11; identical in 2021, p. 10, and 2023, pp. 12–13):
  • "Deductions that are attributable to only one spouse must be claimed by that spouse."
  • "Payments made from accounts owned by both spouses that pertain to expenses not attributable specifically to one spouse can be allocated to either spouse in any proportional amount."
• ARM 42.15.524(3) (in effect 4/30/2010 until its repeal effective 1/25/2025, so it governed TY2021–2023; archived text). It applies to spouses who filed a joint federal return or none, which is how PE treats married units:
  • (a) A deduction "clearly attributable to one spouse may be claimed only by the spouse to whom it is attributable".
  • (b) On the same form, one "not clearly attributable to one spouse may be divided as provided on the form".
  • (c) On separate forms, it "must be divided equally unless the spouses enter into a binding written agreement".

Readings

Provision	PR picks	Alternative	Basis
Status 2a line 1a: dependents' other medical expenses, TY2021–2023	The candidate share with the lowest combined line 20: equal split, all to the head, all to the spouse, and the share at which the two columns' incomes before the dependent exemptions balance. Ties go to the equal split	An equal split (this PR's first version); a full search over every share	I ruled on 2026-10-20 that, since the couple may divide jointly paid bills "in any proportional amount", the model takes the cheapest allocation, from a cheap candidate set wherever only a full search would find the minimum. This PR runs no full search over every share
Who paid a dependent's bill	The model treats every dependent bill as paid from an account both spouses own	Assign some bills to the paying spouse	The model has no payer data; the variable documents this
The separate path's itemize election	The election with the lower combined line 20; ties keep the old larger-deduction rule	Compare summed deductions (before)	2022 Form 2 instructions p. 11: spouses "must either both claim the standard deduction, or both itemize"; MCA 2021 15-30-2132(1): the standard deduction "is allowed if elected by the taxpayer"

The comparisons use each column's tax before refundable credits (Form 2 line 20). Refundable credits don't depend on the deductions, except the 2021 income tax rebate. That rebate can't exceed line 20, and the choices leave it out.

TY2021 objective. In 2021 the choices minimize line 20, not tax net of the 2021 rebate. Couples chose how to file their 2021 returns before the rebate law existed (the repo cites Ch. 44, L. 2023 for the rebate), so line 20 is the tax they could minimize. mt_income_tax_rebate on main documents the same assumption: couples make the separate-versus-joint election before the rebate.

Changes

• tools/mt_separate_return.py (new): the status 2a column formulas as functions (dependent exemption allocation, rate schedule, capital gains tax, medical deduction, and the couple's line 20 for given deductions). mt_taxable_income_indiv, mt_regular_income_tax_indiv, mt_capital_gains_tax_indiv and its threshold now call them, unchanged in result, so the choices evaluate the model's own formulas in closed form, with no simulation branches.
• mt_dependent_medical_expense_head_share (new, TaxUnit): evaluates the couple's line 20 at four candidates (equal split, 0, 1, the balancing share) and takes the lowest.
  • While each column's line 1a exceeds its 7.5% floor, the total deduction doesn't depend on the share, and the tax is convex in it, lowest where the columns' incomes balance.
  • Where a column's line 1a falls short of its floor, bills moved into that column deduct nothing, and the tax is monotone in the share. So the shares where a floor starts to bind never beat 0 or 1, and leaving them out changed no tax or chosen share on the grid below and no test result.
  • The set reaches the minimum except where a column's capital gain credit holds its line 20 at zero.
• mt_non_medical_itemized_deductions_indiv (new): the itemized deductions other than medical, so the choice can hold them fixed; mt_itemized_deductions_indiv adds the medical deduction to it. Since the merge of main it also lists Model the claim of right repayment deduction and credit (26 U.S.C. 1341) and North Carolina's rules that depend on it #10038's mt_misc_deductions_subject_to_floor_indiv, the 2017 pool after its 2% Montana-AGI floor, which main lists in mt_itemized_deductions_indiv.
• mt_medical_and_dental_expenses_indiv (new): line 1a from the chosen share.
• mt_tax_unit_itemizes: the election by tax when the model allows status 2a. The joint path doesn't read it: a single return takes the larger deduction, which can't raise its tax, so the joint path doesn't change.
• spouse_allocation_rate: its description now calls it a modeling convention for status 2a, not a rate in law. Its comment names its four readers: the charitable split in two variables, the medical tie-break and first candidate, and the dependent care deduction, where the equal split is the form's rule. The ARM reference points at archived text, with the 2022 instructions p. 11 and IRS Pub. 502 "Separate returns".

Witness (TY2022: head wages $60,000, spouse $15,000, child's bills $10,250)

Allocation	Montana tax
Main (no dependent bills; standard deduction)	$2,929.68
Standard deduction in both columns	$2,929.68
All to the head, itemizing	$2,789.30 (chosen)
All to the spouse, itemizing	$2,918.36
Equal split, itemizing (this PR's first version)	$2,988.30

We computed these with the model at the round 2 head. Swapping the labels gives $2,789.30 too.

Invariants

Property tests in tests/unit/test_mt_dependent_medical_split_invariants.py run on a seeded population of 40 couples in each of 2021–2023. I dropped an earlier Hypothesis test because it killed none of the mutants. For every couple:

1. The chosen line 20 never exceeds the line 20 at shares 0, 0.5, 1, the two floor kinks (computed in the test from the inputs) and 0.1 to 0.9, when itemizing. Without the capital gain credit, the minimum over all shares falls at a candidate, so the interior shares catch a chooser that misses the balance point.
2. It never exceeds the tax with the standard deduction in both columns.
3. The couple's Montana tax never exceeds its tax before this change (no dependent bills, election by summed deductions).
4. Swapping head and spouse labels leaves the couple's tax unchanged.
5. More dependent bills never raise the couple's tax.

test_closed_form_matches_columns checks that mt_separate_tax_before_refundable_credits with mt_deductions_indiv equals the columns' summed line 20 within $0.01, so the choices minimize the tax the columns compute. It runs 30 couples with wages and long-term capital gains in 2021–2023, so most have a non-zero capital gain credit.

Properties 3–5 use mt_income_tax in 2022–2023 and line 20 in 2021 (the rebate). Each candidate's allocation gives each column at least as much line 1a when the bills grow, so property 5 holds by construction for the candidate set. The tests state and check monotonicity on the tax (5), not on the summed deduction. The chosen allocation can move between columns as bills grow, so nothing guarantees a rise in the summed medical deduction, and no test checks one.

test_mt_medical_premium_deduction_invariants.py property 10 now reads the chosen share (between 0 and 1) instead of assuming 0.5, and its conservation and accounting checks stay as they were.

Sweep (household-level, no microdata)

We measured these figures before the merge of main at 7001052730. We report the population run at the final head under "Microsimulation impact" below.

The sweep covers 1,452 TY2022 couples: head wages $40,000–$90,000 (step $5,000), spouse wages $8,000–$30,000 (step $2,000), and one child with $0–$30,000 of bills (step $3,000).

• Against main (emulated as no dependent bills with the summed-deduction election), 1,091 couples pay less (by up to $1,546.39, mean −$538.59 over all 1,452) and 0 pay more.
• The equal split this PR first used (emulated as a forced equal split with the summed-deduction election) leaves 906 couples paying less than on main and 30 paying more (by up to $66.94). The current code leaves none of the 30 paying more, and property 3 checks that for every generated couple.

Impact

We measured the figures below before the merge of main at 7001052730.

• Who: TY2021–2023 Montana tax units that the model files on the separate path, and reforms that re-enable separate filing.
  • Married couples with dependents' medical bills get the cheaper split.
  • Any status 2a couple whose summed itemized deductions pointed the wrong way now takes the cheaper election. Two existing cases flip: mt_tax_unit_itemizes.yaml (head AGI $20,000, spouse $0) now itemizes ($189.20 against $243.20), although its itemized deductions sum to less; and mt_childcare_itemization_boundary.yaml case 1, whose sums tie, now itemizes ($180.80 against $243.20).
  • For unmarried filers the joint path already counted their dependents' bills, and the model takes the lower tax.
• TY2021: minimizing line 20 can move a couple onto the separate path or between columns in a way that shrinks the 2021 rebate, so post-rebate mt_income_tax can rise (grid witness: $185.20 → $1,413.65).
• Where it flows: mt_itemized_deductions_indiv and mt_tax_unit_itemizes into each column's tax, then mt_files_separately, mt_income_tax, mt_income_tax_before_refundable_credits_unit and the 2021 rebate's cap base.
• CI cost: test_mt_dependent_medical_split_invariants.py runs 6 tests in 23.5 s of pytest time (72 s wall with imports, peak RSS 1.83 GB) in one process. With the earlier Hypothesis test, the file took 36.7 s (90 s wall, 1.95 GB). test_mt_medical_premium_deduction_invariants.py runs 5 tests in 26 s (75 s wall, 1.80 GB). We timed both locally on a 4-vCPU VM, not on Linux CI. The choices add four closed-form evaluations of the columns' line 20 per tax unit, and the election two; no simulation branches.
• Not measured: the default dataset's records start in 2024, after the model turns the separate path off, so no microdata estimate covers TY2021–2023 (see "Microsimulation impact").

Not covered

• PE's SEPARATE filing status: this is the federal status, and a separated head with a qualifying child gets HEAD_OF_HOUSEHOLD first. So a SEPARATE unit with dependents arises only when a household's input sets filing_status, and its head's column then holds all of the dependents' expenses.
  • Couples who filed separate federal returns fall under ARM 42.15.524(2) and the instructions' "report the items of deduction the same way you reported them on your federal Form 1040", which this PR does not model.
  • On separate forms (status 2b), ARM (3)(c) requires an equal split unless the spouses agree otherwise in writing. PE has no separate path for status 2b, though its dependent care deduction treats federal SEPARATE units as filing on a separate form.
• Payer data: PE has none. The model takes each spouse's own expenses as attributable to that spouse, which the instructions require for such expenses and allow for jointly paid ones. It treats every dependent's bill as paid from an account both spouses own. A bill one spouse paid from their own funds belongs to that spouse, and the model can't see such payments.
• Other jointly paid itemized deductions (charitable and the rest) still split equally by spouse_allocation_rate. This PR doesn't split them jointly with the medical bills to minimize tax.
• Credit-bound columns: the balancing share gives the minimum unless the capital gain credit holds a column's line 20 at zero. Where it does, the minimum can sit elsewhere between the floor kinks, and this PR doesn't search for it there. On a 270-couple grid without capital gains (TY2021–2023), the chosen line 20 never exceeds the minimum over 51 forced shares and the standard deduction for any couple.

Main merge (#10038) and tests at this head

• Merge. 7001052730 merges main at ba9bfdea75. I resolved its only conflict, in mt_itemized_deductions_indiv.py, by keeping this PR's version: the non-medical deductions plus the head-or-spouse medical deduction. test_mt_medical_premium_deduction_invariants.py merged without a conflict and keeps both sides: properties 10 and 11 here, and Count eligible long-term care premiums in Schedule A medical expenses #10265's long-term care checks.
• The floor deduction. 96d1045eeb lists mt_misc_deductions_subject_to_floor_indiv in mt_non_medical_itemized_deductions_indiv, beside mt_misc_deductions, as main had it. The balancing share reads that sum, and the itemize election reads mt_itemized_deductions_indiv, which includes it, so both hold the floor deduction fixed. The joint and federal-itemization sums already carry main's floor variables, and tools/mt_separate_return.py builds no list of its own.
• New case in mt_income_tax.yaml, hand-computed before the run. TY2017 is the only year in which the code applies both paths: misc_floor_applies is true only in 2017, and status 2a eligibility returns married_filing_separately_on_same_return_allowed, whose 2021 value extends back. The model's 2017 exemption (2,580), schedule and standard deduction likewise equal its 2021 values, so the case pins the model's arithmetic.
  • Inputs: head $25,000 of Montana AGI and $2,500 of unreimbursed employee expenses; spouse $15,000 and $500 of tax preparation fees; the child's bills $25,000.
  • Floor deductions: 2,500 − 2% × 25,000 = 2,000 and 500 − 2% × 15,000 = 200 (joint 2,200).
  • Share: 0.5 + (22,295 − 13,345) / 50,000 = 0.679, so line 1a is [16,975, 8,025] and itemized deductions [17,100, 7,100].
  • Each column has 5,320 before the child's halved exemption and owes 31 + 930 × 2% = 49.60. The joint return owes 155.80, so mt_income_tax is 99.20.
• Mutant. With the floor variable removed from the list, the new case fails: mt_income_tax.yaml gives 1 failed, 5 passed. A direct run gives share 0.715, itemized deductions [16,000, 6,000] and mt_income_tax 143.20, matching the hand computation.
• Tests at this head (96d1045eeb), one file per process:

File	Result
mt_childcare_itemization_boundary.yaml	2 passed
mt_medical_and_dental_expenses_indiv.yaml	4 passed
mt_medical_expense_deduction_indiv.yaml	13 passed
mt_tax_unit_itemizes.yaml	4 passed
mt_income_tax.yaml	6 passed (the new case included)
test_mt_dependent_medical_split_invariants.py	6 passed
test_mt_medical_premium_deduction_invariants.py	5 passed
Main's mt_claim_of_right_deduction.yaml	35 passed
Main's mt_taxable_income_joint.yaml	8 passed
Main's test_mt_taxable_income_properties.py	1 passed
Main's test_mt_mortgage_interest_federal_limit_properties.py	6 passed

• CI: Pull request run 42773047592 at 96d1045eeb passed all 36 jobs on GitHub's merge with main 833c28bb47.

Overlaps with open PRs

• Cap Montana's 2021–2023 state and local tax deduction once per joint return and at $5,000 per separate column #10002 (per-column SALT cap) and Count a Montana casualty loss once per joint return and only for the spouse who had it #9888 (casualty loss) edit the Montana itemized path that this PR moved into mt_non_medical_itemized_deductions_indiv. Whichever lands second must move its change into the new variable; otherwise the split and the election compare a tax that leaves the change out.
• Count only filer-paid premiums in Schedule A medical expenses #10270 conflicts with this head in 7 files, the same 7 it conflicts with on main, where Count eligible long-term care premiums in Schedule A medical expenses #10265 changed the same federal medical files. One of them, test_mt_medical_premium_deduction_invariants.py, is also in this PR, which adds no conflict of its own. Use the federal itemized total and deduction type for Montana from 2024 #10206 closed without merging.
• Model the claim of right repayment deduction and credit (26 U.S.C. 1341) and North Carolina's rules that depend on it #10038 merged to main as 0296cdbd13. It added mt_misc_deductions_subject_to_floor_indiv, the 2017 pool after its 2% Montana-AGI floor, to the list in mt_itemized_deductions_indiv. This PR's merge of main carries it into mt_non_medical_itemized_deductions_indiv (96d1045eeb).

Review

• r1 at 01fd6e5c6a: REQUEST_CHANGES, no code defects; body, Axiom draft and documentation findings, fixed in b352a51acb.
• r2 / r2b at b352a51acb: REQUEST_CHANGES on two prose claims, then APPROVE.
• Second review at a358eb61d0: APPROVE, with one P2: measure the split in tax. Its witness and grid led to the ruling.
• DTrim99 at a358eb61d0: REQUEST_CHANGES, one should-address item and four suggestions (Round 2 below).
• Round 2 review at 3146e8b86f: REQUEST_CHANGES, three P2s and five P3s (Round 3 below).
• Round 3 review at cad9f36902: APPROVE, four P3s (Round 4 below).
• Round 4 review at c08dd183f6: APPROVE, two P3s (Round 5 below).
• Round 5 delta review at 96d1045eeb: agrees; no P1 or P2; four P3s on this description, the Axiom note and the TY2017 case's years (Round 6 below).

Round 2

Item	Resolution	Commit
Ruling: tax-minimizing split	Candidate-set chooser in closed form; tests expect it	65036f1615, 3dfd4a7333
DTrim99 Should 1: itemize election by tax	mt_tax_unit_itemizes compares the couple's line 20; joint path unchanged; properties 2 and 3	8accee23e7
Suggestion 1: tax-minimizing split	Done (above)	3dfd4a7333
Suggestion 2: spouse_allocation_rate metadata	Modeling convention, archived ARM text, Pub. 502	7102775bc3
Suggestion 3: downstream case	mt_income_tax.yaml: a status 2a couple whose child's bills lower the tax ($2,774.63 against $2,929.68), hand-computed	8accee23e7
Fix after the first push: dependent mask on itemized deductions; second flipped case	Restored the head-or-spouse mask on the medical part; updated the boundary case	3146e8b86f
Suggestion 4: body housekeeping	Local paths and internal terms removed; the follow-up is now in this PR	this body
Not in this PR	Other jointly paid itemized deductions: not split by tax (see Not covered)	—

I merged main in at 07d9af6696.

Round 3

Item	Resolution	Commit
P2-1: the candidate set misses the balance point	Balancing share added; the floor kinks dropped (they only tie 0 or 1; removing them changed no tax, share or test). The review's witness is a case in mt_income_tax.yaml ($131.40 at share 0.715). Low-income grid (90 couples per year, heads $10k–$40k, spouses $5k–$25k, bills $4k/$12k/$25k, employment income, TY2021–2023, against 51 forced shares and the standard deduction): largest gap $51.79 before, $0.00 after	9e2bc13d17, cad9f36902
P2-2: TY2021 disclosure	Impact and the methodology paragraph above; no code change	this body
P2-3: impact: line	Added from the population run at the final head (2026; see Microsimulation impact)	this body
P3-1: closed form unguarded; Hypothesis too thin	test_closed_form_matches_columns with capital gains; property 1 also checks shares 0.1–0.9; Hypothesis test dropped	9e2bc13d17, c6cdfe2df7, cad9f36902
P3-2: spouse_allocation_rate wording	Modeling-convention description; all four readers named	dca8b29047
P3-3: broken links	We restored both links	this body
P3-4: overlaps	Section above	this body
P3-5: mt_files_separately strict comparison	Follow-up	—

I merged main again at bda0215efd (no conflicts).

Round 4

Item	Resolution	Commit
P3-1: credit-bound columns	Follow-up, as disclosed under "Not covered"	—
P3-2: the balancing share's premium term untested (M6 survived)	mt_income_tax.yaml: the balancing witness with $3,000 of premiums on the head; share 0.655, line 1a [16,375, 8,625], line 20 [35.70, 35.70], hand-computed. M6 now fails it	c08dd183f6
P3-3: overlaps	git merge-tree rerun at this head: #10206 clean; #10270 conflicts only in test_medical_expense_premium_conservation.py, as it does against main (superseded at 96d1045eeb; see Overlaps)	this body
P3-4: impact: line	Added from the population run at the final head (2026; see Microsimulation impact)	this body

Round 5

Item	Resolution	Commit
P3-1: the premium case set a derived variable, so its joint return had no premiums	mt_income_tax.yaml: the balancing witness now sets medical_expense_health_insurance_premiums: 3_000 and also asserts mt_income_tax_joint 115.10, mt_files_separately true and mt_income_tax 71.40. M6 still fails it (share 0.715 vs 0.655)	4c615b1c79
P3-2: impact: line	Added from the population run at the final head (2026; see Microsimulation impact)	this body
Overlap with #10038	git merge-tree against #10038's head conflicts only in mt_itemized_deductions_indiv.py; bullet added above	this body

Round 6

Item	Resolution	Commit
P3-1: no impact: line; the sweep and impact figures predate the merge	Population run at the final head (Microsimulation impact below); the sweep and impact sections say when we measured them	this body
P3-2: the Axiom extension still describes the equal split	Update comment on rulespec-us#1520: the tax-minimizing share, with rows for the three TY2022 cases added since	rulespec-us#1520
P3-3: the TY2017 case runs on the model's 2021 parameters carried back	Follow-up: Montana's pre-2021 parameters	—
P3-4: internal terms in this description	Removed	this body

Microsimulation impact

We estimate that this PR changes no output in 2026 on the default dataset: Montana income tax stays at $2.32bn, and no sampled tax unit, person or household changes. We compared main at ba9bfdea75 with this branch at 96d1045eeb.

This PR changes only the separate path, which the model turns off from 2024, when married_filing_separately_on_same_return_allowed turns false. So in 2026 the three separate-column outputs below come to $0 on main and on this branch. No record changes in any output we compared, so the largest single change comes to $0. State and federal income tax, household net income and household benefits don't change.

The default dataset's records start in 2024. We also ran 2021, 2022 and 2023 on it, and every Montana total came to $0 on main and on this branch, so it can't estimate the years this PR changes. The sweep above covers TY2022 household by household.

Output	2026 main	2026 change	2026 records changed (weighted)
mt_income_tax	$2.32bn	$0	0 (0)
mt_medical_expense_deduction_indiv	$0	$0	0 (0)
mt_itemized_deductions_indiv	$0	$0	0 (0)
mt_capital_gains_tax_indiv	$0	$0	0 (0)
state_income_tax	$577.3bn	$0	0 (0)
income_tax	$2,595.3bn	$0	0 (0)
household_net_income	$17,198.7bn	$0	0 (0)
household_benefits	$2,060.5bn	$0	0 (0)

This PR adds mt_medical_and_dental_expenses_indiv, mt_non_medical_itemized_deductions_indiv and mt_dependent_medical_expense_head_share, so main has no total to compare.

impact: no output changes in 2026 on the default dataset (0 sampled records; Montana income tax stays at $2.32bn); the separate path ends after 2023, and the dataset starts in 2024, so TY2021–2023 has no estimate
axiom: TheAxiomFoundation/rulespec-us#1520 queued, extended with two comments (the status 2a line 1a allocation, then the tax-minimizing share at 96d1045eeb with rows for the three TY2022 cases added since). At corpus pin 437198d6, its open prerequisites include the historical ARM 42.15.524, MCA 2021 text for §§ 15-30-2110 and 15-30-2132, and a TY2021–2023 version of the IRC 213 floor rate.

🤖 Generated with Claude Code

[MaxGhenis]

Hand-off to the US + core hub (from session local_bb242a7d, 2026-10-19)

• Head: b352a51acb1bd523756ec2f4acedd75a75d5372d. Ready for review, mergeable, no review comments.
• Independent review: Opus 5.5, standing in for GPT-6.1 Sol. The Codex lanes were closed (reset 19:22Z), and disk pause Add tax parameters #9 blocked new Subfleet jobs.
  • r1 at 01fd6e5c6a: REQUEST_CHANGES, no code defects. The findings were the body's mechanism claims and the Axiom draft.
  • r2 (delta): REQUEST_CHANGES on two prose claims.
  • r2b: APPROVE at b352a51acb, with the current body and the posted Axiom comment.
  • Files: ~/reviews/us-hub/reviews-gen/us-mt-sep-medical/review-r1.md, review-r2.md.
• Passed locally at this head:
  • the two changed YAML files (17 cases);
  • the 24-file MT deduction set (201 cases);
  • test_mt_medical_premium_deduction_invariants.py (5/5);
  • ruff.
• Pending: CI run 39307755299. PR validation and Package and compatibility pass; the rest are queued.
• Depends on: nothing. It merges cleanly with Count only filer-paid premiums in Schedule A medical expenses #10270 (head 2e5fccfd1f), and the MT tests pass on that merge; they can land in either order.
• Decision d1700 (Max, low priority, parks 11/02 if Max is silent): keep the equal split of a dependent's bills between spouses, or allocate them to minimize tax. In my view it doesn't gate the merge. This PR replaces a dropped amount with the equal split the model already uses for the charitable deduction, and any ruling would be a one-formula follow-up. Whether the PR waits for the ruling is the hub's call.
• Axiom: rulespec-us#1520 is queued, with the extension comment.
• Follow-ups owed:
  • a proposed session, "Montana separate filing: itemize by tax, not deduction sums". mt_tax_unit_itemizes compares deduction sums rather than tax, so 24 of 1,452 swept couples pay up to $58.62 more; the body has a witness;
  • the same session should consider float noise in mt_files_separately's strict <.

[DTrim99]

PR Review: Count dependents' medical bills in Montana's separate-filing medical deduction

Summary

The PR adds mt_medical_and_dental_expenses_indiv, which fills Itemized Deductions Schedule line 1a in each column. Each spouse keeps their own other medical expenses, and the expenses of every other member of the unit are split equally between the spouses. An unmarried filer's column takes all of them. mt_medical_expense_deduction_indiv now applies the 7.5% floor to that amount. Before this, a dependent's bills reached neither status 2a column.

• Law. The fix matches TY2021–2023 law. Line 1 takes IRC 213 expenses, which cover a dependent's care. The floor applies to each column's own Montana AGI. If a bill was paid from an account both spouses own, the couple may split it in any proportion, so an equal split is one of the allowed choices. Federal MFS practice also treats such bills as paid equally.
• Code. The code is vectorized, limited to Montana, and limited to 2021–2023 (zero from 2024). It doesn't touch the joint path or non-MT households, and for unmarried filers it doesn't change the tax.
• Tests. The tests check out by hand.
• Axiom. rulespec-us#1520 is open, labelled pe-parity, dispatch-ready, and records its corpus blocker.
• The one problem. Some couples now pay more, and the PR knows it. The equal split interacts with the existing rule in mt_tax_unit_itemizes, which picks itemizing by comparing deduction sums rather than tax. In the author's sweep, 24 of 1,452 TY2022 couples pay up to $58.62 more than on main. That is also more than they would owe if they took the standard deduction, which the law lets them do. The fix is only "proposed as a follow-up session", and no issue tracks it.

Critical (must fix)

None.

Should address

1. Known tax increase for some status 2a couples in claimed years; fix how the itemize election is chosen, or track it before merge.

Files: policyengine_us/variables/gov/states/mt/tax/income/deductions/itemized/medical/mt_medical_and_dental_expenses_indiv.py:50, which interacts with policyengine_us/variables/gov/states/mt/tax/income/deductions/general/mt_tax_unit_itemizes.py:12-14 (itemized_ded > standard_ded, summed over both columns).

What's wrong. Moving a dependent's bills into the columns can tip the summed comparison toward itemizing even when the couple's tax goes up.

The PR body's TY2022 witness: head wages $60,000, spouse $15,000, a child with $10,250 of other medical expenses.

• Standard deductions: 5,090 + 3,000 = 8,090.
• Itemized deductions: 3,409.80 + 4,696.20 = 8,106.00.
• Both columns therefore itemize, and Montana tax rises from $2,929.68 to $2,988.30.

The hand arithmetic agrees. The head's column gives up 1,680.20 of deductions at the 6.75% top rate (about +$113). The spouse's column gains 1,696.20 in the 3–4% brackets (about −$55). The net is about +$58, against the body's $58.62.

Why it's wrong under the law. Montana lets the couple choose the standard deduction. The 2022 Form 2 instructions say "Spouses must either both claim the standard deduction, or both itemize their deductions" (PDF p. 11). MCA 2021 § 15-30-2132(1) says the standard deduction "is allowed if elected by the taxpayer." So this couple would owe at most $2,929.68 under the standard deduction, or $2,789.30 with all of the child's bills in the head's column, which the "any proportional amount" rule allows.

The model elsewhere assumes the couple makes the cheaper choice:

• mt_files_separately takes the lower of the joint and separate taxes.
• mt_taxable_income_indiv says its dependent exemptions are "allocated optimally".
• Federal tax_unit_itemizes compares tax_liability_if_itemizing with tax_liability_if_not_itemizing.

Why this is not critical.

• The PR's own allocation is a legal election.
• The comparison that causes the increase was already there before this PR.
• Main is also wrong for these couples, because it ignores bills they can legally deduct.
• The PR discloses the effect.
• 641 of the 1,452 swept couples pay less.

Even so, merging as is knowingly makes some modeled TY2021–2023 liabilities worse.

Fix (preferred). Make mt_tax_unit_itemizes choose by comparing the couple's combined column tax under each election, using the branch pattern from federal tax_unit_itemizes. Do it in this PR, or in a stacked PR that merges with it. The body reports that this change alone brings the witness back to $2,929.68 and removes all 24 increases. Whatever Max decides on d1700, the change is right, because the election belongs to the couple.

Fallback, if the hub prefers to merge first.

• File the itemize-by-tax change as a policyengine-us issue and link it in the PR body. A "proposed session" is not tracked.
• Record Max's d1700 ruling, or the default of keeping the equal split, on the PR.

Suggestions

1. d1700: consider a tax-minimizing split. The law permits the equal split, but it sits near the worst of the splits the body measured ($2,988.30 at 0.5 against $2,789.30 at all-to-head; the worst split found was 0.45). A tax-minimizing allocation would match how the model already handles the dependent exemptions and the joint-or-separate choice. This is a methodology call, so it is fine as a follow-up once Max rules.

2. spouse_allocation_rate metadata. The parameter is policyengine_us/parameters/gov/states/mt/tax/income/deductions/itemized/spouse_allocation_rate.yaml, which this PR does not change. It now serves medical expenses too.

   • Its description calls 0.5 "a mathematical representation of 'divided equally'". For status 2a, ARM 42.15.524(3)(b) defers to the form, and the form allows "any proportional amount", so for 2a the 0.5 is a modeling convention.
   • Its ARM link points at the live rules site, but the rule was repealed effective 1/25/2025 (LII history: "MAR, 42-1088, Eff. 1/25/2025"). The archived text the new variable cites would serve better, together with the 2022 instructions p. 11.
   • The equal default has a useful federal anchor: IRS Pub. 502, "Separate returns": "Any medical expenses paid out of a joint checking account in which you and your spouse have the same interest are considered to have been paid equally by each of you, unless you can show otherwise."

3. Add a downstream integration case. All the new YAML cases stop at line 1a or the medical deduction. A small mt_income_tax (or mt_income_tax_indiv) case would pin the flow through mt_itemized_deductions_indiv and mt_tax_unit_itemizes. Use a status 2a couple where the dependent's bills lower the tax.

4. PR body housekeeping. The Review section cites local files (~/reviews/us-hub/...) and internal queue terms that outside reviewers can't open. Link the review text or drop the paths.

Verified correct

• Line 1 law. The 2022 instructions (PDF p. 32; 2021 p. 31 and 2023 p. 36 differ only in the year) say "Enter your medical expenses paid in 2022 … The expenses allowed on line 1 are the same medical and dental expenses that are allowed under the Internal Revenue Code." IRC 213(a) covers care "of the taxpayer, his spouse, or a dependent".
• Per-column floor. On the 2022 Form 2 (PDF p. 7), each of columns A and B has "1a … Enter the amount from page 1, line 14 1b … Multiply line 1b by 7.5% (0.075) 1c". So the 7.5% floor applies to each spouse's own Montana AGI, which is what mt_agi_indiv gives. The floor parameter is 0.075 for 2021–2024.
• Allocation rules.
  • The instructions' allocation text is the same in 2021 (p. 10), 2022 (p. 11) and 2023 (pp. 12–13): "Deductions that are attributable to only one spouse must be claimed by that spouse" and "Payments made from accounts owned by both spouses that pertain to expenses not attributable specifically to one spouse can be allocated to either spouse in any proportional amount."
  • The archived ARM 42.15.524(3)(a)–(c) text matches the PR body, and LII confirms the repeal date.
  • MCA 2021 § 15-30-2131 requires an equal split only for the dependent care deduction ((1)(c)(vi)(D): "must be divided equally between the spouses when filing separately on the same form"). It has no medical-specific allocation rule. Nothing in these sources conflicts.
• The spouse split.
  • The model has no data on who paid. Each spouse keeps their own expenses, and other members' expenses are split 0.5/0.5. Both choices fall within "any proportional amount" if the bills were paid from a joint account, and the federal default for such bills is an equal split. An unmarried filer takes everything.
  • Swapping which spouse is labelled head doesn't change the result.
  • The columns add up to the joint return's line 1 base. itemized_medical_expenses is premiums minus the excluded premiums plus other_medical_expenses, so the joint variant counts every member's expenses, as the pool does.
• Code.
  • Vectorization is correct (where and tax_unit.sum; the scalar if in the deduction is on a parameter).
  • The new variable is on Person, like the other _indiv variables.
  • defined_for = "mt_married_filing_separately_on_same_return_eligible" limits it to MT, and to 2021–2023 because the allowed-flag parameter is false from 2024.
  • The NH Add New Hampshire state supplementation for 2026 #10156 pattern doesn't apply: no state-gated int or enum variable is used as a parameter or breakdown key.
  • Non-MT households and the joint path (mt_medical_expense_deduction_joint) are unchanged.
  • For unmarried filers, the separate path now matches the joint path. Their tax can't go up: there is one column, and the final tax is the lower of joint and separate.
  • Readers: mt_itemized_deductions_indiv, and mt_itemized_deductions_for_federal_itemization_indiv. The latter feeds only state_itemized_deductions, which no formula reads.
• Hand-checked expectations (12).
  • New file, TY2021 couple, both labellings: [2,000, 2,700, 0, 0, 2,000, 2,700, 0, 0]. The pool is 3,000 + 1,000 = 4,000, half to each spouse, and the spouse's own 700 is added to that spouse's column.
  • New file, TY2022 unmarried: [1,000, 0] (100 + 900).
  • New file, TY2024: eligible is [false, false] and line 1a is [0, 0]. This is the 2024 non-effect.
  • New file, TY2023 non-dependent relative: [500, 500, 0].
  • Deduction file, TY2022 couple, line 1a: [4,000, 3,500, 0, 4,000, 3,500, 0].
  • Same case, deduction: [0, 2,000, 0, 0, 2,000, 0]. The earner gets max(0, 4,000 − 0.075 × 60,000) = 0. The partner gets 3,500 − 0.075 × 20,000 = 2,000. This checks the floor on each spouse's own AGI.
  • TY2023 head of household: line 1a is 4,000; the separate deduction is 4,000 − 2,250 = 1,750, the same as the joint deduction of 1,750.
  • TY2024 reform: line 1a is [2,000, 2,000, 0]. The deductions are head (2,000 premiums + 2,000) − 3,000 = 1,000 and spouse 2,000 − 750 = 1,250.
  • Invariants test property 10: the closed form filer × own + share × pool matches the formula. It is conserved within each unit, and dependents get 0.
  • The PR body's witness: the standard and itemized totals (8,090 against 8,106) and the size of the tax increase, as worked out above.
• Changelog. changelog.d/fix-mt-separate-medical-dependents.fixed.md is a top-level fragment with the fixed type.
• References. Each source is cited once, and multi-page hrefs carry a # PDF pages … comment. The 2022 instructions p. 11 anchor shows the allocation text.
• Source-conflict guard (Tie source-conflict markers to the register shared with Axiom #10287). None of the comment lines in the two changed variable files match CONFLICT_COMMENT_RE or ATTEMPT_RE. Neither file is in KNOWN_UNMARKED, and the PR changes no parameter files. So test_source_conflicts.py passes on the merged tree; I checked this statically.
• Partner tests. No files under tests/policy/baseline/partners/** are touched.

Axiom line assessment

The line is axiom: rulespec-us#1520 queued, with an extension comment.

• State. rulespec-us#1520 is OPEN and labelled pe-parity.
• Extension comment. Posted 2026-10-19; it covers PR head b352a51acb. The current head, a358eb61d0, only merges main into that commit. It leaves the PR's six files unchanged, so the comment still describes this head.
• Dispatch-ready. The comment has everything the rules ask for:
  • the module path (us-mt/statutes/15-30-2131/1/a.yaml, medical component, extended to status 2a);
  • corpus citations for the TY2021–2023 Form 2 and instructions rows, and the MCA 2021 § 15-30-2131 row;
  • the law verbatim: the instructions' allocation text, line 1, ARM 42.15.524(3)(a)–(c), and IRC 213(a);
  • required outputs 10–12: the per-column line 1a with the couple's election s taken as an input and no default, conservation, and the per-column floor;
  • companion cases 7–10, worked from the form and instructions rather than PE output. Cases 7 and 10 match the PR's YAML (4,000/0 and 3,500/2,000; 4,000 and 1,750).
• Blocker. The comment records it: ARM 42.15.524 (the 2010 version) is missing from the corpus. The issue's other prerequisites are also still open: §§ 15-30-2110 and 15-30-2132 exist only as repeal markers, and IRC 213's floor rate has no TY2021–2025 version.
• Methodology. The equal split is fenced off correctly as a PE projection and kept out of the legal outputs.

The line is valid.

CI status

All 27 checks pass at a358eb61d0 (gh pr checks 10276). That includes the four Baseline states shards, which run the MT YAML, and the Python Rest shards, which run test_mt_medical_premium_deduction_invariants.py. Household API Partners, PR validation and Quick Feedback also pass. No checks are pending.

I did not rerun anything locally. CI covers the PR's tests at this head, and the witness figures above are the PR's own, checked against hand arithmetic.

Branch status

The branch is 4 commits ahead of main and 34 behind. git merge-tree --write-tree PolicyEngine/main a358eb61d0 merges cleanly, with no conflicts. Since the merge base, main has changed mt_itemized_deductions_indiv (mortgage insurance premiums), which doesn't overlap this PR. #10270 is still open; it edits other hunks of the invariants test file.

Verdict: REQUEST_CHANGES

[DTrim99]

The law checks out: line 1 includes dependents under IRC 213, the floor is on each column's own MT AGI, and an equal split is a legal joint-account allocation. One should-address item: the equal split plus the summed test in mt_tax_unit_itemizes makes some couples itemize at a higher tax than the standard deduction the law lets them take (e.g. $2,929.68 -> $2,988.30). Choose itemizing by comparing tax, here or in a stacked PR, or file a tracked issue. Four suggestions. Full report in the comment above.

[MaxGhenis]

Picking this up for the US hub. I'll post a hand-off comment here when it's ready.

---

Generated by Claude Code

[MaxGhenis]

Ready for hub review

Head: 3146e8b86f6ee122bab2750682c2356ec9603e5c (fast-forward from a358eb61d0, which was the head at pick-up; nobody else had pushed in the six hours before). Main was merged in with a merge commit at 07d9af6696, cleanly.

What was asked and how it's resolved

1. Tax-minimizing split in closed form, no branches (65036f1615, 3dfd4a7333).

• tools/mt_separate_return.py (new) holds the status 2a column formulas as functions: dependent exemption allocation, rate schedule, capital gains threshold and tax, medical deduction, floor room, and mt_separate_tax_before_refundable_credits (:173), which gives the couple's summed line 20 for given per-person deductions.
• mt_taxable_income_indiv, mt_regular_income_tax_indiv, mt_capital_gains_tax_indiv and its threshold, and mt_medical_expense_deduction_indiv now call those functions. Their results are unchanged: the MT folder runs below pass at the head.
• mt_dependent_medical_expense_head_share (new, TaxUnit): the candidates are s = 0.5 (spouse_allocation_rate), 0, 1, and the two floor kinks (:81). Ties within $0.01 go to the share closest to 0.5 (:92).
• mt_non_medical_itemized_deductions_indiv (new) splits the non-medical part out of mt_itemized_deductions_indiv, so the choice holds it fixed without a cycle.
• No fallback to branches was needed.

2. Every dependent bill treated as jointly paid. Documented at mt_medical_and_dental_expenses_indiv.py:15, with the own-funds caveat (review r1b P2-1). The formula is at :51.

3. Tests expect the minimizing allocation; witness under the final code. TY2022, head wages $60,000, spouse $15,000, child's bills $10,250, computed with the model at this head:

Allocation	Mine	Hub's figure
Main (standard deduction)	$2,929.68	$2,929.68
All to the head, chosen	$2,789.30	$2,789.30
Equal split, itemizing	$2,988.30	$2,988.30
All to the spouse	$2,918.36	—

No differences. Swapping the labels gives $2,789.30 too. The chosen share is 1.0 and the couple itemizes.

Updated YAML in mt_medical_expense_deduction_indiv.yaml, hand-computed in the comments:

• :174, 2022: the child's bills all go to the partner. Tax saved is $268.90 at s = 0, against $168.75 at s = 1, $118.90 at s = 0.5, and $90.00 and $101.25 at the kinks.
• :281, 2024 reform: all go to the head. Savings are $177.00, against $152.75, $117.75, $105.75 and $132.75.

The zero-income cases in mt_medical_and_dental_expenses_indiv.yaml tie, so they keep 0.5, and the comments say so.

4. Invariants as Hypothesis property tests. tests/unit/test_mt_dependent_medical_split_invariants.py (new): Hypothesis with 6 examples of up to 6 couples, plus a 40-couple seeded population for each of 2021–2023. It checks:

• (1) chosen line 20 ≤ every candidate's, including 0.5, with the kinks computed in the test from the inputs;
• (2) ≤ the standard deduction in both columns;
• (3) mt_income_tax ≤ main's, emulated as no dependent bills with the summed-deduction election;
• (4) label swap;
• (5) more bills never raise the tax.

The requested "deduction monotone non-decreasing in the bills" is stated and tested as (5), on the tax. Each candidate gives each column at least as much line 1a when the bills grow, so the tax form holds by construction. A monotone summed deduction isn't guaranteed and isn't tested; I didn't look for a counterexample.

2021 uses line 20, not mt_income_tax, because of the rebate. Property 10 of test_mt_medical_premium_deduction_invariants.py (:432) now reads the chosen share instead of assuming 0.5.

5. Body readings. The body has a Readings table (the candidate-set split per the ruling, with the full search logged as an optimization; the jointly paid assumption; the election). The axiom: line is unchanged.

DTrim99 Should 1: itemize election by tax (8accee23e7). mt_tax_unit_itemizes.py:41: when status 2a is allowed, the couple itemizes if the combined line 20 is lower itemizing (at the chosen split) than with both standard deductions. A tie within $0.01 keeps the old summed-deduction rule, and so do years without status 2a. It's in closed form, with no branches.

• I read the joint path first. mt_taxable_income_joint takes max_(itemized, standard) and doesn't read the flag, so the joint path doesn't change.
• New invariants (2) and (3) are in the property tests.
• mt_tax_unit_itemizes.yaml:62: the new election case, with the share forced to 0.5. Summed itemized 8,325 > standard 8,090, but the tax is $2,973.66 against $2,929.675, so the couple doesn't itemize.
• :19: an existing case flips (head AGI $20,000, spouse $0; summed itemized 6,050 < standard 6,260). Itemizing gives $189.20 against $243.20, so it now itemizes. The expectation and comment are updated. This is the intended effect, and it's not a partner test.
• Sweep: the body's 1,452-couple grid script wasn't available to me, so I ran my own household-level TY2022 grid. Heads earn $40k–$90k in $5k steps, spouses $8k–$30k in $2k steps, and the child's bills run $0–$30k in $3k steps: 1,452 couples, no microdata.
  • New code against main: 1,091 lower (up to $1,546.39), 0 higher.
  • Emulated old head (forced equal split with the summed-deduction election): 906 lower, 30 higher, up to $66.94. That doesn't reproduce the body's 641/24, so the grid differs from the reviewer's.
  • Property (3) proves no increase over main for every generated couple.
• CI time: no branches, so no extra simulations. The cost is five plus two closed-form line-20 evaluations per tax unit. For CI timing, see CI below.

Suggestion 2: spouse_allocation_rate (7102775bc3). spouse_allocation_rate.yaml:3: described as a modeling convention for status 2a (the charitable split, and the medical tie-break and first candidate). References: archived ARM 42.15.524, 2022 instructions p. 11, and IRS Pub. 502 "Separate returns".

Suggestion 3: downstream case (8accee23e7). mt_income_tax.yaml:41: a status 2a couple with Montana AGI and other itemized deductions as inputs.

• All bills go to the head and the couple itemizes. Line 20 is [2,491.03, 283.60] and the joint return is 3,224.08, so the couple files separately with mt_income_tax 2,774.63, against 2,929.675 under the standard deduction.
• Every candidate's tax is hand-computed in the comment.

Fix after the first push (3146e8b86f): the itemized-deduction mask and the second flipped case, described under Tests.

Suggestion 4: body housekeeping. Local paths, queue ids and fleet terms are removed. The follow-up is now in this PR.

Not in this PR: splitting the other jointly paid itemized deductions to minimize tax. The body logs it as a later optimization, along with the full search over medical splits.

The body has a Round 2 table and the witness under the final code.

Tests (one file per process, at the head's tree)

• Changed YAML:

  • mt_medical_and_dental_expenses_indiv.yaml: 4 passed;
  • mt_medical_expense_deduction_indiv.yaml: 13 passed;
  • mt_tax_unit_itemizes.yaml: 4 passed;
  • mt_income_tax.yaml: 3 passed.

• Python:

  • test_mt_dependent_medical_split_invariants.py: 4 passed, about 75 s in pytest (52.6 s for the Hypothesis test; 6.7, 3.1 and 2.7 s for the seeded years);
  • test_mt_medical_premium_deduction_invariants.py: 5 passed, about 60 s.

  These are local timings on a 4-vCPU VM, not Linux CI; peak memory wasn't measured.

• MT deduction folder (22 files) plus the top-level MT tax files the refactor touches and the capital gains and rebate files, 39 files: all pass, 306 cases.

  • The first pass found two failures, both since fixed in 3146e8b86f and rerun (2 and 7 passed).
  • mt_itemized_deductions_indiv.yaml was a real regression from my split of the itemized deductions: a medical deduction supplied as an input for a dependent wasn't masked to the head and spouse. The mask is restored.
  • mt_childcare_itemization_boundary.yaml case 1 has summed deductions that tie at 6,260, but itemizing gives $180.80 against $243.20. It now itemizes, the second existing case to flip.
  • The same two cases failed CI's states-shard-4 at 7102775bc3 (run 41409280516); the fix was the only re-push.

• ruff check and ruff format: clean.

Mutants (each in its own process, restored after)

• The chooser always returns 0.5: 3 of 4 property tests fail.
• The election reverts to summed deductions: 3 of 4 fail.

CI

• Pull request run 41416732622 at 3146e8b86f: completed, success, 34 of 34 jobs.
• The earlier run 41409280516 at 7102775bc3 failed only in states-shard-4, on the two cases described under Tests.
• I have no per-test CI timing for the new property file. This run's Python Rest shards took 20–29 minutes each; I didn't compare them against a main run.

Judgment calls

• The objective is the couple's line 20 (before refundable credits). The 2021 rebate is capped at line 20 per column, so it's left out of the choice and documented.
• The tie tolerance is $0.01, for both the split and the election. An election tie keeps the old rule, so unmarried filers whose taxes tie are unchanged.
• The candidate set uses spouse_allocation_rate as the equal-split candidate and tie target. If a reform changes the rate, the tie target moves with it.
• Refactoring the column formulas into shared functions makes the comparison evaluate exactly what the columns compute; the property tests confirm it against forced inputs. The capital gains tax functions apply only from 2024 (reform years).
• Added the 2021 (PDF p. 10) and 2023 (PDF pp. 12–13) instruction references to line 1a (Sol P3-4). Those page numbers are from the reviews, not fetched.
• I wrote the MCA 2021 15-30-2132 URL by the repo's existing mca.legmt.gov pattern. I couldn't fetch it (the host is refused here), so it's unverified, and so are the quoted 2022 instruction and MCA phrases, which come from DTrim99's review.
• No # Source conflict markers.

Follow-ups to propose

• Full search over the status 2a medical split. Search every breakpoint (bracket boundaries and exemption reallocation) instead of the five candidates, and report how much it lowers tax beyond the candidate set.
• Allocate the other jointly paid status 2a itemized deductions to minimize tax. The charitable and other jointly paid deductions still split 50/50; optimize them jointly with the medical split.
• mt_files_separately float tolerance (Sol P3-1). The strict < lets float32 noise flag unmarried filers as filing separately; add a small tolerance.

---

Generated by Claude Code

[MaxGhenis]

Hub review in progress

Superseded by the final review: #10276 (comment)

---

Generated by Claude Code

[MaxGhenis]

Ready for hub review
VERDICT: REQUEST_CHANGES
3146e8b
METHODOLOGY_CHOICE: yes

The head hasn't moved since the hand-off. This is a delta review of a358eb61d0..3146e8b86f. It includes the merge of main at 07d9af6696; that merge touches none of this PR's files.

The code does what it says:

• the refactored column variables compute what main computed;
• the closed form equals the column chain;
• the itemize election works by tax, and a tie keeps the old rule;
• every hand value I recomputed matches;
• all changed tests pass, and CI is green (34 of 34 jobs).

Two things need changing before merge:

• P2-1. The five-candidate split misses the true minimum for some lower-income couples, by up to $55.95. One more closed-form candidate closes every gap I found. Max's rule is to minimize where it's cheap, and here it is cheap.
• P2-2. In TY2021, the couple's post-rebate mt_income_tax can rise against main, by up to $1,228.45 on my grid. The body's Impact section doesn't say so.

P2-3 is a missing impact: line. DTrim99's should-address item is resolved; see the table at the end.

Findings

P2-1. The candidate set misses the minimum where the columns' incomes can be balanced

Where: policyengine_us/variables/gov/states/mt/tax/income/deductions/itemized/medical/mt_dependent_medical_expense_head_share.py:84-89, the candidate list. The docstring at :31-36 and the body's "Not covered" bullet blame "a bracket boundary between candidates".

Why the set misses it. Let s be the head's share.

• Between the two floor kinks, every extra dollar of bills is deductible in either column, so the total deduction doesn't depend on s.
• The columns share one rate schedule, and the dependent exemptions already flow to the larger column (mt_allocate_dependent_exemptions). So the couple's tax is convex in s on that segment. It is lowest where the two columns' incomes balance, to within the dependent exemptions.
• Below a column's kink, that column wastes the bills it is given. So the tax is monotone on each outer segment, and a kink candidate can at most tie s = 0 or s = 1.
• So the minimum is at 0, at 1, or at the balancing point. The code tries the first two and the kinks, but not the balancing point.

Witness (TY2022), with Montana AGI as input so the federal return doesn't enter: head $25,000, spouse $15,000, other itemized deductions 0, one child with $25,000 of other medical expenses.

• By hand from the 2022 schedule in main/separate.yaml (2,710 exemptions; floors 1,875 and 1,125):

  • equal split $187.35; all to the head $203.20; all to the spouse $720.80; head kink (s = 0.075) $720.80; spouse kink (s = 0.955) $206.10;
  • standard deduction $620.60; joint return $214.80;
  • on a 1,001-point grid, the minimum is $131.40, reached for s between 0.627 and 0.78.
  • At s = 0.715 both columns have 6,290 before the child's exemption, so each has 4,935 after it, and each owes 33 + 1,635 × 2% = 65.70.

• The model at the head gives mt_dependent_medical_expense_head_share = 0.5, line 20 = [178.20, 9.15], mt_files_separately = true and mt_income_tax = 187.35. That is $55.95 above the minimum.

• With employment income instead of Montana AGI inputs, I used 90 couples per year: heads $10k–$40k, spouses $5k–$25k, child's bills $4k, $12k and $25k. I compared the chosen line 20 against 51 forced shares plus the standard deduction:

  Year	Couples above the grid minimum by more than $1	Largest gap
  2021	10 of 90	$53.98
  2022	12 of 90	$55.95
  2023	10 of 90	$50.90

  On a higher-income grid (heads $40k–$90k), 0 of 120 couples miss, because both columns sit in the 6.75% bracket.

Fix: add the balancing share as a candidate. On the segment between the kinks, the head's column income is level_h − s·pool and the spouse's is level_s − (1 − s)·pool, where level is each column's income with its line 1a exactly at its floor. Insert this before candidates = [:

        # The share at which the two columns' incomes before the dependent
        # exemptions are equal: between the floor kinks the total deduction is
        # fixed and the couple's tax is convex in the share, lowest where the
        # columns balance.
        kink_deduction = mt_medical_deduction(
            person, period, parameters, own_expense + room
        )
        level = (
            person("mt_agi_indiv", period)
            - person("mt_personal_exemptions_indiv", period)
            - other_itemized
            - kink_deduction
            + room
        )
        gap = tax_unit.sum(level * head) - tax_unit.sum(level * spouse)
        balance = np.clip(0.5 + gap / (2 * safe_pool), 0, 1)

Then add balance, to candidates.

What the fix does:

• With this as a scratch edit (since reverted), all 90 couples in each of 2021, 2022 and 2023 sit at or below the grid minimum (largest gap $0.00). For the witness it picks 0.715 and gives $131.40.
• It costs one more closed-form evaluation per tax unit.
• The kink candidates can then go, or stay as harmless ties.

Also do these:

• Update the docstring's last two sentences of the candidate description and the body's "Not covered" bullet.
• Add the witness above as a YAML case on mt_income_tax.

The tests don't detect the gap:

• Property 1 only compares the chosen tax with the candidates themselves.
• Deleting both kink candidates (mutant M3 below) fails no test.

P2-2. TY2021: the couple's post-rebate tax can rise against main, and the body doesn't say so

Where: the body's Impact, Sweep and Invariants sections. The mechanism is in mt_income_tax_before_2021_rebate (unchanged): it picks joint or separate by line 20 and then caps each column's rebate at that column's line 20.

What happens. This PR lowers the separate path's line 20. That moves some couples from joint to separate, where a low-income spouse's column has little line 20 for the rebate to refund.

Witness (TY2021): head wages $60,000, spouse $5,000, child's bills $8,000.

	Main	This head
Separate line 20	2,851.49 + 2.80	2,663.65 + 20.82 = 2,684.47
Joint line 20	2,685.20	2,685.20
Return used (mt_files_separately)	joint	separate (by $0.73)
Rebate	1,250 + 1,250	1,250 + 20.82
mt_income_tax	$185.20	$1,413.65

On a 240-couple TY2021 grid against main (heads $5k–$60k, spouses $0–$30k, bills $0–$25k), 10 couples pay more, by up to $1,228.45, and 12 pay less. On the same grid in TY2022 and TY2023, 0 pay more: 75 and 68 pay less, by up to $754.38 and $807.88. This agrees with the body for those years.

Whether line 20 is the right objective in 2021 is a methodology call (see the table below), so this finding is about disclosure:

• The body's "0 pay more" is TY2022 only.
• Invariant 3 is tested on line 20 in 2021. That's stated in the Invariants paragraph, but Impact doesn't carry it.
• Add to Impact: "TY2021: minimizing line 20 can move a couple onto the separate path or between columns in a way that shrinks the 2021 rebate, so post-rebate mt_income_tax can rise (grid witness: $185.20 → $1,413.65)."

The line-20 choice in mt_income_tax_before_2021_rebate predates this PR, but this PR makes it reachable for these couples. Either confirm the reading with Max, or file it as a follow-up with this witness.

P2-3. The body has no impact: line

• Where: the PR body. grep -n '^impact:' finds nothing; the axiom: line exists.

• Fix: add a line, for example:

  impact: TY2021–2023 MT status 2a couples; lowers mt_income_tax in 2022–2023 (0 increases in property tests and grids); TY2021 post-rebate tax can rise (P2-2); needs an MT microsim for TY2021–2023.

P3-1. The property tests don't pin the closed form against the column variables, and the Hypothesis test is too thin to catch the hand-off's mutants

Where: policyengine_us/tests/unit/test_mt_dependent_medical_split_invariants.py:216-230 (Hypothesis with 6 derandomized examples) and :79-120 (Montana AGI as an input, no capital gains).

Mutants, each a scratch edit in its own run, restored afterwards; git status is clean:

Mutant	Property file (4 tests)	YAML (deduction, tax unit itemizes, income tax)
M1: the share is always 0.5 (hand-off)	3 fail: test_seeded_population[2021/2022/2023]; the Hypothesis test passes	not run
M2: the election by summed deductions (hand-off)	3 fail, the same three; the Hypothesis test passes	not run
M3 (mine): drop both kink candidates	4 pass	13, 4, 3 pass. Survives.
M4 (mine): the closed form ignores mt_non_refundable_credits	4 pass	13, 4, 3 pass. Survives.

M4 matters. The hand-off says "the property tests confirm it against forced inputs". They don't compare the closed form with the columns, and they never generate capital gains, so the 2021–2023 capital gain credit is always 0.

• I checked equality directly: with employment income and long-term capital gains, over 60 random couples per year, |closed form − Σ mt_income_tax_before_refundable_credits_indiv| is at most $0.0008. The credit is non-zero in 47, 43 and 43 units.
• So the code is right today, but nothing guards it.
• Fix: add one test asserting mt_separate_tax_before_refundable_credits(tax_unit, period, parameters, mt_deductions_indiv) equals the summed column line 20, on couples with capital gains. Raise Hypothesis max_examples, or drop the Hypothesis test, since the seeded tests do all the killing.

P3-2. spouse_allocation_rate states a convention as law

• Where: policyengine_us/parameters/gov/states/mt/tax/income/deductions/itemized/spouse_allocation_rate.yaml:1.
• Problem: "Montana allocates this share …" contradicts the comment below it, which says the share is a modeling convention. The comment also omits two other readers: mt_child_dependent_care_expense_deduction, where an equal split is statutory, and mt_itemized_deductions_for_federal_itemization_indiv.
• Fix: description: Montana itemized deductions paid jointly are split by this share between the spouses' columns when married couples file separately on the same form; this is a modeling convention, not a rate in law. Then add both readers to the comment.

P3-3. Two broken links in the body

• Where: the body's "Law" bullets.
• Problem: ([2022 instructions, PDF p. 32](``https://…#page=32)):``` and (```https://…#page=11);````. The stray backticks break both links.
• Fix: remove the backticks so each reads ([2022 instructions, PDF p. 32](https://…#page=32)).

P3-4. Coordinate with open PRs that edit the moved code

• Where: mt_itemized_deductions_indiv.py.
• Problem: Cap Montana's 2021–2023 state and local tax deduction once per joint return and at $5,000 per separate column #10002 (per-column SALT cap) conflicts with this head in that file. Count a Montana casualty loss once per joint return and only for the spouse who had it #9888 (casualty loss) edits the same itemized path; it conflicts elsewhere with this head. Both predate the split into mt_non_medical_itemized_deductions_indiv.
• Whoever resolves them must move their changes into the new variable. Otherwise the split and the election compare a tax that leaves those changes out. Use the federal itemized total and deduction type for Montana from 2024 #10206 and Count only filer-paid premiums in Schedule A medical expenses #10270 also conflict with this head (merge-tree exits 1), but not in the moved formula.
• Command: git merge-tree --write-tree pr-10276 pr-<n> exits 1 for all four. For Cap Montana's 2021–2023 state and local tax deduction once per joint return and at $5,000 per separate column #10002 the conflict is CONFLICT (content): Merge conflict in …/itemized/general/mt_itemized_deductions_indiv.py.

P3-5. Carried over from the earlier round

mt_files_separately's strict < lets float noise flag unmarried filers as separate. It's still at the head. The hand-off lists it as a follow-up; I couldn't confirm an issue exists.

Methodology choices

Provision	PR pick	Alternative	Numbers
Status 2a line 1a split of dependents' bills (ARM 42.15.524(3)(b); the form allows "any proportional amount")	Minimize line 20 over {0.5, 0, 1, two kinks}; ties go to 0.5	Exact minimum (add the balancing share, P2-1)	Witness $187.35 against $131.40; up to $55.95 on the low-income grid; 0 gap on the high-income grid
Objective in TY2021	Line 20, rebate left out	Line 20 net of the 2021 rebate	$185.20 (main) against $1,413.65 (head) for one couple. The repo's own source for the rebate is Ch. 44, L. 2023, which supports line 20 as what couples actually minimized when they filed their 2021 returns. That's Max's call
Who paid a dependent's bill	All paid from a joint account	Payer attribution	No data; documented on the variable
Election	By couple's line 20; tie keeps summed-deduction rule	By summed deductions (main)	Flips two existing cases; YAML verified

DTrim99's review, item by item

Item	Status at head	Evidence
Should 1: itemize election by tax	Resolved	mt_tax_unit_itemizes.py:41-55 compares the couple's line 20, and a tie keeps the old rule. The joint path doesn't read the flag (its only readers are mt_deductions_indiv and the tool). The new YAML case (8,325 itemized > 8,090 standard, yet 2,973.66 > 2,929.675) passes. M2 is killed. The 2022 and 2023 grids show 0 increases against main; 2021 is under P2-2
Suggestion 1: tax-minimizing split	Mostly done	Candidate set, see P2-1
Suggestion 2: spouse_allocation_rate metadata	Done, with a wording slip	Archived ARM, 2022 instructions p. 11 and Pub. 502 are cited; see P3-2
Suggestion 3: downstream mt_income_tax case	Done	I recomputed every figure by hand: 2,774.625 chosen; 2,903.80 all to the spouse; 2,973.662 equal split; 2,997.10 and 2,850.5625 at the kinks; 2,929.675 standard; joint 3,224.075
Suggestion 4: body housekeeping	Done	No local paths or queue terms; the follow-ups are listed. Two links are broken (P3-3)

Every should-address item is resolved. The hub can dismiss DTrim99's CHANGES_REQUESTED with a note pointing to 8accee23e7 and the table above.

Checked and sound

• The defect, at main (6145ad4513), TY2022, head wages $60,000, spouse $15,000, child's bills $10,250:
  • mt_medical_expense_deduction_indiv = [0, 0, 0] and the joint deduction is 4,625 (10,250 − 7.5% × 75,000);
  • mt_income_tax = 2,929.675.
• The witness, at the head:
  • chosen share 1.0; line 20 = 2,505.55 + 283.75 = $2,789.30;
  • standard $2,929.68; equal split $2,988.30; all to the spouse $2,918.36. On 201 forced shares the worst is $3,011.36 at 0.44;
  • I didn't rerun the label swap on the witness. Label invariance is property 4, which passes. A note for anyone re-running this: Core treats a formula variable supplied for some tax units as supplied for all of them, so run forced shares in a separate simulation from free ones.
• The refactor:
  • mt_taxable_income_indiv, mt_regular_income_tax_indiv, mt_capital_gains_tax_indiv, mt_capital_gains_tax_applicable_threshold_indiv and mt_medical_expense_deduction_indiv call functions whose code is line-for-line main's. I diffed against merge base 97b6d5135c. The only change is that line 1a replaces other_medical_expenses.
  • Closed form = columns to $0.0008, as under P3-1.
• No cycle, and the right objective for 2022–2023:
  • Montana's non-refundable credits are only mt_capital_gain_credit (2% of net gains, independent of deductions).
  • Its refundable credits (EITC, the elderly homeowner/renter credit, the 2021 rebate) don't depend on the deductions except through the rebate's line-20 cap.
• The candidate kinks: room / pool and 1 − room / pool match the test's independent _kinks.
• The tie-break: a tie within $0.01 keeps the share closest to spouse_allocation_rate.
• The tests, one process per file:
  • mt_childcare_itemization_boundary.yaml 2 passed; mt_medical_and_dental_expenses_indiv.yaml 4; mt_medical_expense_deduction_indiv.yaml 13; mt_tax_unit_itemizes.yaml 4; mt_income_tax.yaml 3;
  • test_mt_dependent_medical_split_invariants.py 4 passed (105 s, peak 1.9 GB RSS); test_mt_medical_premium_deduction_invariants.py 5 passed (98 s);
  • command: python -m policyengine_core.scripts.policyengine_command test <file> -c policyengine_us and pytest -q -p no:cacheprovider <file>.
• Readers of the changed variables:
  • mt_dependent_medical_expense_head_share → mt_medical_and_dental_expenses_indiv → mt_medical_expense_deduction_indiv → mt_itemized_deductions_indiv and mt_itemized_deductions_for_federal_itemization_indiv (which feeds state_itemized_deductions);
  • mt_tax_unit_itemizes → mt_deductions_indiv → columns → mt_files_separately, mt_income_tax, mt_income_tax_before_refundable_credits_unit, mt_income_tax_before_2021_rebate / mt_income_tax_rebate;
  • mt_itemized_deductions_indiv is also listed in _generate_state_mfs_variables.py.
  • None is made worse in 2022–2023 on my grids. 2021 is under P2-2.
• Impact: baseline outputs move only for TY2021–2023 Montana tax units on the status 2a path. The variables that move are line 1a, the medical and itemized deductions, the election, column taxes, mt_files_separately, mt_income_tax, the 2021 rebate, and state_income_tax and net income downstream. That calls for a Montana microsim for TY2021, 2022 and 2023, split by year, counting increases separately in 2021.
• Scope: nothing under .github/ or tests/policy/baseline/partners/.
• CI: run 41416732622 at the head: 34 of 34 jobs succeeded.

What I couldn't check

• Sources: this session's network refused every source host:

  • revenuefiles.mt.gov, mca.legmt.gov and archive.legmt.gov;
  • web.archive.org and law.cornell.edu;
  • govinfo.gov, uscode.house.gov, ecfr.gov, leg.mt.gov and irs.gov.

  So I didn't verify MCA 2021 § 15-30-2132(1), the 2021–2023 Form 2 instructions' quoted phrases and page numbers (pp. 10, 11, 12–13, 32), ARM 42.15.524 or Pub. 502. The new MCA 2132 URL uses the bills/2022/mca/ path, labelled MCA 2021, like the repo's existing § 2131 citation; I couldn't open it.

• Population impact: no microdata here.

• Axiom: rulespec-us#1520 is outside this session's GitHub scope, so I couldn't check whether the queued extension still matches the tax-minimizing split and the election.

• Follow-up issues: I couldn't confirm the issues the hand-off proposes exist.

• The author's grid: the body's 1,452-couple sweep script isn't public. My grids are my own, so their counts don't match the body's.

---

Generated by Claude Code

[MaxGhenis]

Picking this up for the US hub. I'll post a hand-off comment here when it's ready.

---

Generated by Claude Code

[MaxGhenis]

Ready for hub review
cad9f36

Round 3 of #10276, answering the round 2 review at 3146e8b86f. Before pushing, I checked that the head was still 3146e8b86f with no push in the previous 6 hours.

Commits

Commit	What
bda0215efd	Merge origin/main. No conflicts. Main's only Montana changes are documentation on the 2021 rebate (mt_income_tax_rebate, rebate/amount.yaml, mt_refundable_credits).
9e2bc13d17	P2-1 balancing share; witness YAML case; P3-1 closed-form guard test
dca8b29047	P3-2 spouse_allocation_rate wording
c6cdfe2df7	Property 1 also checks forced shares 0.1–0.9
cad9f36902	Kink candidates dropped; Hypothesis test dropped; YAML hand computations note the balancing share

Items

1. Pick-up and merge. Pick-up comment posted. Main merged with a merge commit, no conflicts. All seven of this PR's test files were rerun after the merge (counts below).

2. P2-1, the balancing share (mt_dependent_medical_expense_head_share.py:80-109)

• Derivation, checked against the column formulas.

  • From mt_medical_floor_room: in 2021–2023, room = floor − own. So line 1a at own + room sits exactly at the floor, and kink_deduction is the premiums alone.
  • A column above its floor then has agi − exemptions − other − premiums − (own + s·pool − floor) = level − s·pool before the dependent exemptions.
  • From 2024 (the else branch), room also subtracts the premiums and kink_deduction is 0. The identity is the same.
  • Setting level_h − s·pool = level_s − (1−s)·pool gives s = 0.5 + gap/(2·pool). That is the review's code.

• Kinks: dropped.

  • On [0, head_kink] the head's column is below its floor. Moving bills toward the head only wastes them, so the tax is non-decreasing and s = 0 weakly beats head_kink. Symmetrically, s = 1 weakly beats spouse_kink.
  • Removing both kinks changed no tax and no chosen share on the grid (all 270 couples identical) and no test result (M3 below).
  • The tests still compute the kinks independently and check the chosen tax against them.

• Docstring. Lines 19-44 now give the four candidates and why they reach the minimum. Exception: a column whose capital gain credit holds its line 20 at zero. The body's "Not covered" bullet says the same.

• Witness YAML. New case in mt_income_tax.yaml:107-160, worked by hand from the 2022 schedule:

  • Levels and share. Exemptions 2,710; floors 1,875 and 1,125. level_h = 25,000 − 2,710 + 1,875 = 24,165 and level_s = 15,000 − 2,710 + 1,125 = 13,415, so s = 0.5 + 10,750/50,000 = 0.715.

  • Head column. Line 1a 17,875, deduction 16,000, income 6,290.

  • Spouse column. Line 1a 7,125, deduction 6,000, income 6,290.

  • Tax. The child's 2,710 is halved, leaving 4,935 in each column. Each owes 33 + 1,635 × 2% = 65.70, so the total is 131.40.

  • Alternatives:

    Allocation	Tax
    Equal split	187.35
    All to the head	203.20
    All to the spouse	22,290 − 2,710 = 19,580 → 470 + 4,180 × 6% = 720.80
    Standard deduction	429 + 191.60 = 620.60
    Joint return	9,870 → 214.80

  • Model. It gives share 0.715 and line 20 of [65.70, 65.70]; mt_files_separately is true and mt_income_tax is 131.40.

  • Existing cases. Their hand computations now note where the balancing share falls: it clips to 1 in all three, because the incomes differ by more than the bills. Example: 58,790 − 12,715 = 46,075 against 10,250 of bills.

• Grid.

  • Shape. Employment income; heads 10, 16, 22, 28, 34 and 40k; spouses 5–25k in 5k steps; one child with 4k, 12k or 25k of bills. That is 90 couples per year, TY2021–2023.
  • Comparison. Chosen line 20 against the minimum over 51 forced shares (itemizing) plus the standard deduction, with the forced shares in a separate simulation.

  Code	2021	2022	2023
  Round 2 head	9 of 90 > $1, max $51.79	9, max $45.90	7, max $40.40
  Balancing share, kinks kept	0, max $0.00	0, $0.00	0, $0.00
  Final (kinks dropped)	0, max $0.00	0, $0.00	0, $0.00

  • Largest gap left: $0.00. My grid is smaller than the review's, and its worst couple at the round 2 head was (22k, 10k, 25k bills).

3. P2-2, the 2021 objective. No code change. The body's Impact section has the review's TY2021 sentence verbatim. A methodology paragraph ("TY2021 objective", under Readings) says the 2021 choice minimizes line 20 and why: the rebate law is HB 192, Ch. 44, L. 2023, which I checked is the repo's source. It also notes that main's new mt_income_tax_rebate documentation states the same assumption.

4. P3-1, guarding the closed form.

• New test. test_closed_form_matches_columns[2021/2022/2023] (test_mt_dependent_medical_split_invariants.py:233-297). Each year has 30 couples with wages, long-term capital gains, own medical bills and a child's bills.

• What it checks. It asserts that mt_separate_tax_before_refundable_credits(tax_unit, period, parameters, mt_deductions_indiv) equals the summed mt_income_tax_before_refundable_credits_indiv within $0.01. It also asserts that mt_non_refundable_credits is positive in at least half the units, so the guard can't pass vacuously.

• Hypothesis: dropped. It killed neither mutant MB nor M4 at 6 examples. Under MB at max_examples=30 it still passed (65 s of pytest time). It generates no capital gains, so it can never reach M4. The seeded and closed-form tests do all the killing.

• Property 1 now also compares with forced shares 0.1–0.9. That is what lets the seeded tests see a missing balancing share.

• Wall time and peak memory per file (local 4-vCPU VM, one process, not Linux CI):

  File	Tests	pytest time	Wall	Peak RSS
  test_mt_dependent_medical_split_invariants.py, final	6	23.5 s	72 s	1.83 GB
  same file at c6cdfe2df7 (with Hypothesis)	7	39.9 s	93 s	1.95 GB
  test_mt_medical_premium_deduction_invariants.py	5	26.2 s	75 s	1.80 GB

5. P3-2, spouse_allocation_rate (spouse_allocation_rate.yaml:1-21, description on line 1).

• Description: the review's text, verbatim.
• Comment: names all four readers:
  • mt_non_medical_itemized_deductions_indiv and mt_itemized_deductions_for_federal_itemization_indiv (the charitable split);
  • mt_dependent_medical_expense_head_share;
  • mt_child_dependent_care_expense_deduction, where the equal split is the rule ("each spouse enters one-half of Form 2441-M line 7", as that variable's code states).
• Unverified statute. I couldn't read the MCA to call the dependent-care split statutory: mca.legmt.gov, archive.legmt.gov and web.archive.org were all refused by this session's proxy. So the comment says "the law's rule" and cites the form.

6. P3-3, broken links: partly blocked. The body file I sent had clean links. But both revenuefiles.mt.gov URLs come back from GitHub wrapped in two or three backticks, however they're written from this session:

• gh api PATCH, inline links;
• angle-bracket links;
• the GitHub MCP tool;
• reference-style definitions.

Other URLs in the body are untouched. So I removed those two URLs from the body. It now cites "2022 Form 2 instructions, PDF p. 32 / p. 11" and points to mt_dependent_medical_expense_head_share's references, which carry the p. 11 link. The body now reads back byte-identical to what I sent, with no backticks. If the hub wants the URLs inline, it should add them from a session where this rewriting doesn't happen.

7. P3-4, overlaps. New section "Overlaps with open PRs" in the body:

• Cap Montana's 2021–2023 state and local tax deduction once per joint return and at $5,000 per separate column #10002 and Count a Montana casualty loss once per joint return and only for the spouse who had it #9888 must move their changes into mt_non_medical_itemized_deductions_indiv, whichever lands second.
• Use the federal itemized total and deduction type for Montana from 2024 #10206 and Count only filer-paid premiums in Schedule A medical expenses #10270 are textual conflicts outside the moved formula.

I didn't touch those PRs.

8. Left for the hub. P2-3 (impact: line) and P3-5 (mt_files_separately's strict <). The axiom: line is unchanged.

9. Mutants. Each ran in its own process across all seven test files. Each was restored after its run, and git status was clean after each.

Mutant	Killed by
MB: drop the balancing candidate (kinks still present)	mt_income_tax.yaml witness case (1 of 4 fails); test_seeded_population[2022], [2023]
M3: drop both kink candidates	Survives all 7 files: 2, 4, 13, 4 and 4 YAML cases pass; 7 and 5 Python tests pass. Expected, since the balancing share makes the kinks redundant; cad9f36902 then made this the shipped code.
M4: closed form ignores mt_non_refundable_credits	test_closed_form_matches_columns[2021], [2022], [2023] only

Tests at cad9f36902

One process per file:

File	Result
mt_childcare_itemization_boundary.yaml	2 passed
mt_medical_and_dental_expenses_indiv.yaml	4 passed
mt_medical_expense_deduction_indiv.yaml	13 passed (peak 5.3 GB)
mt_tax_unit_itemizes.yaml	4 passed
mt_income_tax.yaml	4 passed
test_mt_dependent_medical_split_invariants.py	6 passed
test_mt_medical_premium_deduction_invariants.py	5 passed

Commands: uv run python -m policyengine_core.scripts.policyengine_command test <file> -c policyengine_us and uv run pytest -q -p no:cacheprovider <file>. No full suites or microsimulations were run.

CI

Pull request run 41746413835 at cad9f36902: completed, success, 36 of 36 jobs (finished by 01:31Z; this line was updated after the run finished).

Judgment calls

• Kinks dropped, not kept. The brief allowed either. The monotonicity argument plus the identical grid and test results favour four candidates over six.
• Hypothesis test dropped, not raised. At 30 examples it still missed MB and cost about 65 s.
• Property 1's interior grid (0.1–0.9) relies on the no-credit setting of the seeded population. The closed-form test, which has credits, checks equality, not optimality.
• No PR links for the two instruction pages (item 6).
• Dependent care split. Called "the law's rule … Form 2441-M line 7", not "statutory", because I couldn't read the MCA.

Proposed follow-ups

• Montana status 2a: minimize the dependent medical split where the capital gain credit binds. When a column's line 20 is held at zero by the credit, the minimum can sit between the floor kinks away from the balance point. A one-dimensional search on that segment, or a credit-aware balance point, would close it.
• mt_files_separately: compare with a tolerance. Its strict < lets float noise flag unmarried filers as filing separately (round 2 review P3-5). A $0.01 tolerance, as in mt_dependent_medical_expense_head_share, would match.

---

Generated by Claude Code

[MaxGhenis]

Hub review in progress

Superseded by the final review: #10276 (comment)

---

Generated by Claude Code

[MaxGhenis]

Ready for hub review
VERDICT: APPROVE
cad9f36
METHODOLOGY_CHOICE: yes

The head hasn't moved since the hand-off. This is a delta review of 3146e8b86f..cad9f36902, which includes the merge of main at bda0215efd. That merge touches none of this PR's 20 files.

The round 2 fixes hold:

• The balancing share matches my derivation from the column formulas, in 2021–2023 and in the 2024 branch.
• Dropping the kinks loses nothing: they are dominated by 0 and 1 analytically, and a 101-share search agrees.
• The witness case matches my hand computation exactly.
• The closed-form guard kills M4.
• The 2021 disclosure is in the body.
• The tests: all seven changed test files pass, and CI is green (36 of 36 jobs).

I found no P1 or P2. Four P3s follow. The largest is the credit-bound exception the body already discloses: it moves line 20 by up to $60.30 on my grid, but final mt_income_tax by at most $14.10. I give a cheap fix for a follow-up.

The impact: line is still missing, as the fix brief left it for the hub's Montana run. It must be added before landing.

Findings

P3-1. Where the capital gain credit holds a column at zero, the candidate set misses the minimum. A cheap exact fix exists

Where: policyengine_us/variables/gov/states/mt/tax/income/deductions/itemized/medical/mt_dependent_medical_expense_head_share.py:104-108, the candidate list. The docstring at :35-38 and the body's "Credit-bound columns" bullet disclose this.

Why the set misses it. Between the floor kinks, each column's line 20 is max(g(t) − credit, 0), which is still convex in the share. But while one column's line 20 is held at zero, moving income into that column is free. So the minimum sits where that column's pre-credit tax just reaches its credit. That point isn't 0, 1 or the balancing share.

Witness (TY2022): head $10,000 wages and $10,000 of long-term gains, spouse $20,000 wages, one child with $25,000 of other medical expenses.

• At the head, the share is 0.5 and line 20 is [0, 65.70]: each column has taxable income 4,935, and the head's 65.70 is wiped out by its $200 credit.
• The minimum is at share 0.263. There the head's taxable income is 9,500, and its tax 176 + 600 × 4% = 200 equals the credit. The spouse's taxable income is 370, taxed 3.70. So line 20 is [0, 3.70].
• Final tax: the joint return already beats 65.70, so mt_income_tax moves only from −31.32 to −42.42.

Grid, a script of my own:

• 144 couples a year, TY2021–2023: heads $10k–$60k, spouses $0–$20k, child's bills $4k/$12k/$25k, and long-term gains of none, $10k to the head, $10k to the spouse, or $30k each.
• Chosen line 20 against 101 forced shares plus the standard deduction, with the forced shares in a separate simulation.

Year	Couples above the minimum by > $0.05	Largest line-20 gap	Couples without gains, or with gains in both columns
2021	6 of 144	$59.95	$0.00
2022	6 of 144	$60.30	$0.00
2023	5 of 144	$55.20	$0.00

Final tax. The joint path absorbs most of the gap in final mt_income_tax:

• 2022: 4 of 144 couples, by at most $14.10;
• 2021 and 2023: 0.

Fix, for a follow-up. Search the convex middle segment. I tested this as a scratch edit, since reverted. Insert it before candidates = [, and add searched, to the list:

        # Between the floor kinks the couple's tax is convex in the share,
        # also when a column's capital gain credit holds its line 20 at
        # zero, so a ternary search there reaches the minimum.
        head_room = tax_unit.sum(room * head)
        spouse_room = tax_unit.sum(room * spouse)
        low = np.clip(head_room / safe_pool, 0, 1)
        high = np.maximum(np.clip(1 - spouse_room / safe_pool, 0, 1), low)
        for _ in range(40):
            third = (high - low) / 3
            left, right = low + third, high - third
            left_lower = couple_tax(left) < couple_tax(right)
            high = where(left_lower, right, high)
            low = where(left_lower, low, left)
        searched = (low + high) / 2

What the fix does:

• Grid: every couple in all three years sits at or below the 101-share minimum. The largest gap is $0.00; the search beats the grid by up to $1.70, because it lands between grid points.
• The witness: it picks 0.263 and gives line 20 of 3.70.
• Tests: the PR's tests still pass (mt_income_tax.yaml 4 passed; test_mt_dependent_medical_split_invariants.py 6 passed).
• Cost: 80 closed-form evaluations per tax unit. 25 iterations would be enough.
• Alternative: a closed-form candidate per column, inverting the rate schedule at the credit. It needs the dependent-exemption allocation inverted too.

Property 1 can't detect this: its seeded population has no capital gains, as its docstring says.

Follow-up title: "Montana status 2a: reach the minimum when the capital gain credit holds a column at zero". Use the witness above and the fix code.

P3-2. The balancing share's premium term is untested (mutant M6 survives)

• Where: mt_dependent_medical_expense_head_share.py:95-101. Nothing tests the - kink_deduction term in level. In 2021–2023 that term is the column's medical and long-term care premiums.

• Mutant M6 deletes that line. Every changed test file passes under it: mt_income_tax.yaml 4 passed; the split property file 6 passed; the premium property file 5 passed. The seeded population and the YAML witness have no premiums.

• Witness that kills it (TY2022): the balancing witness plus mt_eligible_medical_insurance_premiums: 3_000 on the head.

  • By hand: the head's level is 25,000 − 2,710 − 3,000 + 1,875 = 21,165 and the spouse's is 13,415. So s = 0.5 + 7,750 / 50,000 = 0.655.
  • Head column: line 1a 16,375, deduction 14,500 + 3,000 = 17,500, income 4,790.
  • Spouse column: line 1a 8,625, deduction 7,500, income 4,790.
  • After halving the child's 2,710, each column has 3,435 and owes 33 + 135 × 2% = 35.70.
  • The head gives share 0.655 and line 20 [35.70, 35.70]. M6 gives 0.715 and [32.90, 38.60], $71.50 in total.

• Fix: add a YAML case to mt_income_tax.yaml (or mt_medical_and_dental_expenses_indiv.yaml) with these inputs. Assert:

  • mt_dependent_medical_expense_head_share: 0.655;
  • mt_medical_and_dental_expenses_indiv: [16_375, 8_625, 0];
  • mt_income_tax_before_refundable_credits_indiv: [35.70, 35.70, 0].

  The share assertion kills M6. The tax alone wouldn't, because both shares fall in the 2% bracket.

P3-3. The body's overlap section is out of date

• Where: the body's "Overlaps with open PRs" section, second bullet.
• What it says: "Use the federal itemized total and deduction type for Montana from 2024 #10206 and Count only filer-paid premiums in Schedule A medical expenses #10270 conflict with this PR textually, outside the moved formula."
• What I ran: git merge-tree --write-tree --name-only pr-10276 pr-<n>:
  • Use the federal itemized total and deduction type for Montana from 2024 #10206 (head c1b942f276) exits 0. It no longer conflicts.
  • Count only filer-paid premiums in Schedule A medical expenses #10270 conflicts only in policyengine_us/tests/core/test_medical_expense_premium_conservation.py, which this PR doesn't touch. The same conflict appears against main (bda0215efd^1), so main causes it. Count dependents' other medical expenses in Idaho's claimant medical worksheet #10278 is the same.
  • Count a Montana casualty loss once per joint return and only for the spouse who had it #9888 and Cap Montana's 2021–2023 state and local tax deduction once per joint return and at $5,000 per separate column #10002 conflict with this PR in mt_itemized_deductions_indiv.py and others. The body's first bullet about them stands.
• Replacement for the second bullet: "Use the federal itemized total and deduction type for Montana from 2024 #10206 now merges cleanly with this PR, and Count only filer-paid premiums in Schedule A medical expenses #10270's only conflict is with main, in a file this PR doesn't touch."

P3-4. The body still has no impact: line

• grep -n '^impact:' on the body finds nothing; the axiom: line is there.
• The fix brief leaves this line to the hub's Montana run.
• What the diff can move at baseline: TY2021–2023 Montana tax units on the status 2a path. A Montana microsimulation for each of TY2021, 2022 and 2023 should count increases separately in 2021. My TY2021 rebate witness still rises from $185.20 at main to $1,413.65 at the head, as the body now discloses.

Methodology choices

Provision	PR pick	Alternative	Numbers
Status 2a line 1a split of dependents' bills (the form allows "any proportional amount", per the body's quotes; I couldn't fetch the source)	Lowest line 20 over {0.5, 0, 1, balancing share}; ties go to 0.5	Add a search on the middle segment (P3-1)	Line 20 up to $60.30 above the minimum; final tax up to $14.10 (4 of 432 couples)
Objective in TY2021	Line 20, rebate left out. The reason: couples filed their 2021 returns before the rebate law (Ch. 44, L. 2023, the repo's cited source)	Line 20 net of the rebate	$185.20 at main against $1,413.65 at the head for one couple; disclosed in Impact
Who paid a dependent's bill	All paid from a joint account	Payer attribution	No data; documented on the variable
Itemize election	By the couple's line 20; a tie keeps the summed-deduction rule	Summed deductions (main)	Unchanged since round 2

Checked and sound

• Head and range. The head is cad9f36902 and the PR is open and not a draft. The PR's own commits after the merge are 9e2bc13d17, dca8b29047, c6cdfe2df7 and cad9f36902. git diff bda0215efd^1 bda0215efd -- <PR files> is empty.

• The balancing share, derived by hand from mt_separate_return.py:

  • 2021–2023. room = 0.075·AGI − own, so mt_medical_deduction(own + room) is the premiums alone, and level = AGI − exemptions − other − premiums + 0.075·AGI − own. Above its floor, a column's deduction is own + c·pool − 0.075·AGI + premiums. So its income before the dependent exemptions is level − c·pool, with c = s for the head and 1 − s for the spouse. Setting the two equal gives s = 0.5 + (level_h − level_s) / (2·pool). That is the code.
  • 2024 branch. room also subtracts the premiums, the kink deduction is max(0, premiums + own + room − floor) = 0, and the same identity follows.

• A column at or below its floor. On [0, head_kink] the head's deduction is fixed, and the spouse's falls as s rises. Each column's tax is non-decreasing in its income, and so is the exemption allocation. So the couple's tax is non-decreasing there, and s = 0 weakly beats head_kink. The same holds for s = 1 on [spouse_kink, 1]. If the computed balance falls outside the middle segment, the middle minimum is at a kink, which 0 or 1 dominates. So an out-of-range balance is a harmless candidate. If the kinks cross (room_h + room_s > pool), the middle segment has both columns below their floors and the tax is flat there.

• Pool = 0. safe_pool avoids a division by zero, and :121 returns the equal split, which has no effect.

• Dropping the kinks. The argument above holds. On my grid, couples without gains or with gains in both columns sit at $0.00 against 101 forced shares in every year.

• 2024+ reform check. I ran the TY2024 path under a reform that sets married_filing_separately_on_same_return_allowed to true. On 24 couples, gains included, the gap is $0.00. The standard deduction wins for most of them, so this check is weak.

• The witness case (mt_income_tax.yaml:107-160), recomputed in a script from the 2022 separate schedule, independent of the model:

  • share 0.715; 6,290 in each column before the child's exemption and 4,935 after; 65.70 per column; 131.40 in total;
  • equal split 178.20 + 9.15 = 187.35; all to the head 203.20; all to the spouse 720.80;
  • standard deduction 429 + 191.60 = 620.60; joint return 214.80.

  The model gives the same at the head. On a 1,001-point grid the minimum is 131.40, flat for shares 0.627 to 0.803.

• The closed-form guard (test_mt_dependent_medical_split_invariants.py:233-297):

  • It uses assert_allclose(closed_form, columns, atol=0.01).
  • It requires mt_non_refundable_credits > 0 in at least half the units.
  • Its couples have wages and long-term gains.
  • M4 fails it in all three years at line 297, and only there.

• Mutants, each a scratch edit in a separate worktree, one process per file, restored afterwards. git status is clean in both trees.

  Mutant	Killed by
  MB: drop balance	mt_income_tax.yaml (1 of 4 fails, the witness); test_seeded_population[2022], [2023]. The other four YAML files and the premium property file pass
  M4: closed form ignores mt_non_refundable_credits	test_closed_form_matches_columns[2021/2022/2023] only; all five YAML files and the premium property file pass
  M5 (mine): sign flip, 0.5 - gap / (2 * safe_pool)	mt_income_tax.yaml (1 fails); test_seeded_population[2022], [2023] (line 193)
  M6 (mine): drop - kink_deduction	Survives; see P3-2

• The defect, at main (25c4253483), TY2022: head wages $60,000, spouse $15,000, child's bills $10,250.

  • At main, mt_medical_expense_deduction_indiv = [0, 0, 0] and mt_income_tax = 2,929.68.
  • At the head, the share is 1.0, line 20 is [2,505.55, 283.75] and mt_income_tax is 2,789.30.
  • The balancing witness gives 214.80 (joint) at main and 131.40 at the head.

• The 2021 objective.

  • mt_income_tax_rebate on main documents that "the separate-versus-joint filing election is determined before this rebate by assumption". Its reference is HB 192, Ch. 44, L. 2023, so the body's reasoning matches the repo's source.
  • mt_separate_tax_before_refundable_credits leaves the rebate out, as its docstring says.
  • The body's Impact section carries the TY2021 disclosure word for word. My rerun of its witness gives $185.20 at main and $1,413.65 at the head.

• spouse_allocation_rate:

  • The description is the round 2 text.
  • The comment names all four readers, which I confirmed by grep: mt_non_medical_itemized_deductions_indiv:31, mt_itemized_deductions_for_federal_itemization_indiv:31, mt_dependent_medical_expense_head_share:56 and mt_child_dependent_care_expense_deduction:46.

• Readers. The delta adds none. mt_dependent_medical_expense_head_share is read by mt_medical_and_dental_expenses_indiv, and through the tool by mt_tax_unit_itemizes. mt_non_medical_itemized_deductions_indiv is read by mt_itemized_deductions_indiv and the share. mt_tax_unit_itemizes is read only by mt_deductions_indiv. The round 2 reader list stands.

• Body statements checked against the code:

  • the four candidates;
  • the dropped kinks and the Hypothesis test;
  • the 40-couple seeded population and the 30-couple guard;
  • property 1's interior shares 0.1–0.9;
  • the "Credit-bound columns" caveat, which my grid confirms: every gap is in a one-sided-gains couple;
  • the TY2021 objective paragraph.

  The two instruction links are still absent; the hub restores them.

• Tests at the head, one process each:

  File	Result	Wall	Peak RSS
  mt_childcare_itemization_boundary.yaml	2 passed	129 s	2.21 GB
  mt_medical_and_dental_expenses_indiv.yaml	4 passed	175 s	3.13 GB
  mt_medical_expense_deduction_indiv.yaml	13 passed	252 s	5.43 GB
  mt_tax_unit_itemizes.yaml	4 passed	132 s	2.53 GB
  mt_income_tax.yaml	4 passed	131 s	2.54 GB
  test_mt_dependent_medical_split_invariants.py	6 passed (32.5 s pytest)	109 s	1.87 GB
  test_mt_medical_premium_deduction_invariants.py	5 passed (39.4 s pytest)	113 s	1.84 GB

  Wall times are inflated because a grid ran alongside. The premium file needs hypothesis, a dev dependency that uv sync left out here, so I installed it before rerunning.

• CI: Pull request run 41746413835 at cad9f36902: completed, success, 36 of 36 jobs.

• Scope: nothing under .github/ or policyengine_us/tests/policy/baseline/partners/. The changelog fragment is a top-level changelog.d/fix-mt-separate-medical-dependents.fixed.md.

• Open PRs on the changed files (search API): Count a Montana casualty loss once per joint return and only for the spouse who had it #9888, Cap Montana's 2021–2023 state and local tax deduction once per joint return and at $5,000 per separate column #10002, Use the federal itemized total and deduction type for Montana from 2024 #10206, Count only filer-paid premiums in Schedule A medical expenses #10270 and Count dependents' other medical expenses in Idaho's claimant medical worksheet #10278. See P3-3.

What I couldn't check

• Sources. This session's network refused leg.mt.gov, archive.legmt.gov, mca.legmt.gov, revenuefiles.mt.gov, revenue.mt.gov, web.archive.org, govinfo.gov, uscode.house.gov, ecfr.gov and rules.mt.gov. So I didn't verify:
  • HB 192 / Ch. 44, L. 2023 and its enactment date, which the 2021 reasoning rests on;
  • MCA 2021 § 15-30-2132(1);
  • the 2021–2023 Form 2 instructions' quoted phrases and page numbers;
  • ARM 42.15.524;
  • IRS Pub. 502's joint-account statement in the spouse_allocation_rate comment.
• Population impact: no microdata here. See P3-4.
• Axiom: rulespec-us#1520 is outside this session's GitHub scope.
• The author's grids: the body's 1,452-couple sweep and 270-couple grid scripts aren't public. My grids are my own.
• Mutant runs: the first run hit the session's 30-minute background limit after M4's fourth YAML file. I reran the rest of M4 (the income tax YAML and both property files), plus M5 and M6, on those three files only. M5 and M6 didn't run against the other four YAML files.

---

Generated by Claude Code

[MaxGhenis]

Picking this up for the US hub. I'll post a hand-off comment here when it's ready.

---

Generated by Claude Code

[MaxGhenis]

Ready for hub review

Head: c08dd183f68fabaff6f73f2335420a9ba48d1d54 (one commit on top of cad9f36902; nobody else pushed to the branch while I worked, and main merges cleanly, so I made no merge commit).

⚠️ The two Montana instruction links are broken again, and I couldn't restore them from here

Every body write from this session wraps the two revenuefiles.mt.gov links in backticks. Both write paths do it: gh api -X PATCH through the session's proxy, and the GitHub MCP update_pull_request. The file I sent had both links intact (the hub's restored version). In the stored body, the two links in "Law, and the choice it leaves" (Line 1, PDF p. 32; Allocation between columns, PDF p. 11) are now wrapped in two and three backticks, from the URL through the following punctuation, so they render as code, not links.

Other links in the same write came through untouched, including the web.archive.org link and #9894's law.lis.virginia.gov and tax.nd.gov links. So the rewrite targets that domain, and it is probably what broke these links in earlier rounds too. I didn't try to work around it. The hub needs to restore the two links again from its own machine. The rest of the body matches what I sent, apart from one extra blank line before the footer.

What the round 3 review asked for, and what I did

#	Item	Resolution
12	P3-2: premium term untested	New case "The balancing share counts the head's medical insurance premiums", mt_income_tax.yaml:162-203. It is the balancing witness plus mt_eligible_medical_insurance_premiums: 3_000 on the head. It asserts share 0.655, mt_medical_and_dental_expenses_indiv [16_375, 8_625, 0] and mt_income_tax_before_refundable_credits_indiv [35.70, 35.70, 0], with the review's arithmetic in comments. It passes at the head, and M6 fails it (below).
13	P3-3: overlap bullet	I reran git merge-tree --write-tree --name-only (below); the review's result holds, so the bullet is now the hub's sentence.
14	Runs	All pass; see below.

The case's margin. I used absolute_error_margin: 0.01 rather than the balancing case's 0.05, so the share assertion separates shares 0.01 apart.

Body. Besides the overlap bullet, I added a line to "Review" and a "Round 4" table. The table records P3-1 as a follow-up and P3-4 (impact:) as left for the hub. The impact: line is still absent, as the brief says.

Hand computation (TY2022, 2022 separate schedule)

Step	Head column	Spouse column
Level	25,000 − 2,710 − 3,000 + 1,875 = 21,165	13,415
Line 1a	16,375	8,625
Deduction	14,500 + 3,000 = 17,500	7,500
Income	25,000 − 2,710 − 17,500 = 4,790	15,000 − 2,710 − 7,500 = 4,790
After half the child's 2,710	3,435	3,435
Tax (line 20)	33 + 135 × 2% = 35.70	35.70

The share is s = 0.5 + (21,165 − 13,415) / 50,000 = 0.655, and the total is 71.40.

Mutant M6 (delete - kink_deduction from level)

M6 ran in its own process on a scratch worktree, which I removed afterwards; git status is clean.

• mt_income_tax.yaml: 1 failed, 4 passed. The new case fails with mt_dependent_medical_expense_head_share 0.715 against 0.655, and the runner stops at that first mismatch.
• Direct run of the same household under M6: share 0.715, line 1a [17,875, 7,125], line 20 [32.90, 38.60], mt_income_tax 71.50. At the head: 0.655, [16,375, 8,625], [35.70, 35.70], 71.40.
• So the per-column line 20 also kills M6. Only the total, 71.50 against 71.40, is close.

git merge-tree --write-tree --name-only

Run at cad9f36902 and at the new head; both give the same result.

Pair	Result
this PR vs #10206 (c1b942f276)	exit 0, clean
this PR vs #10270 (2e5fccfd1f)	exit 1, conflict only in policyengine_us/tests/core/test_medical_expense_premium_conservation.py
#10270 vs main (25c4253483)	exit 1, the same file
this PR vs main	exit 0, clean
#10206 vs main	exit 0, clean

This PR doesn't touch test_medical_expense_premium_conservation.py; #10270 does, and main changed it since (e.g. #10109).

Tests at the head (one process per file)

File	Result
mt_income_tax.yaml	5 passed
test_mt_dependent_medical_split_invariants.py	6 passed (33.5 s pytest, 108.7 s wall, 1.79 GiB peak RSS)
test_mt_medical_premium_deduction_invariants.py	5 passed (45.9 s pytest, 121.9 s wall, 1.76 GiB peak RSS)

The premium file needs Hypothesis, so I installed the dev extras first. The two property files ran at the same time, so their wall times are somewhat inflated. No Python file changed in this round, so there was nothing for ruff to check.

CI

Not finished at the 60-minute mark; the runners were congested. This is the only run at this head: the Pull request run 41861893133 at c08dd183f6.

At 16:50Z, 60 minutes after my 15:50Z push, the run was in_progress:

• 34 of 36 jobs had succeeded: all eleven Baseline shards (the four state shards included), Household API Partners, PR validation, Package and compatibility, Quick Feedback, Microsimulation, the Rest Python planning and check jobs, all nine Rest Python shards, and seven Contrib shards.
• 2 were still running: Contrib other-shard-1 and other-shard-3.
• None had failed or been cancelled.

The hub needs to read the run's conclusion.

Judgment calls

• The 0.01 margin (above).
• The Round 4 table and the Review line, which follow the body's existing per-round record.
• The links: I reported them rather than working around the rewrite.

Proposed follow-up

None beyond the review's own P3-1, "Montana status 2a: reach the minimum when the capital gain credit holds a column at zero", which the body already logs.

---

Generated by Claude Code

[MaxGhenis]

Hub review in progress

Round 4 delta review of cad9f36902..c08dd183f68fabaff6f73f2335420a9ba48d1d54. The head hasn't moved.

So far:

• CI: Pull request run 41861893133 at c08dd183f6 completed with success, 36 of 36 jobs.
• Body links: both revenuefiles.mt.gov links (PDF p. 32 and p. 11) render as <a href> in the API's body_html.
• Overlap: git merge-tree --write-tree --name-only: this head vs Use the federal itemized total and deduction type for Montana from 2024 #10206 (c1b942f276) exits 0; vs Count only filer-paid premiums in Schedule A medical expenses #10270 (2e5fccfd1f) conflicts only in test_medical_expense_premium_conservation.py, and Count only filer-paid premiums in Schedule A medical expenses #10270 vs main (25c4253483) conflicts in the same file. The body's bullet holds.
• Still running: the premium case recomputation, M6 and my own mutant, and the test files.

---

Generated by Claude Code

[MaxGhenis]

Ready for hub review
VERDICT: APPROVE
c08dd18
METHODOLOGY_CHOICE: yes

This is the round 4 delta review of cad9f36902..c08dd183f6. The head hasn't moved past the hand-off. The delta is one commit that adds 43 lines to mt_income_tax.yaml (the premium case at lines 162–203); no code changed. Main is 4 commits ahead of the merge base (#10307, #10600 and two version bumps), and none of them touches Montana. The PR merges cleanly with main.

The round 3 items are resolved:

• P3-2, the premium term: the new case matches my hand computation and kills M6.
• P3-3, the overlap bullet: I reran merge-tree and the bullet holds.
• CI is green: 36 of 36 jobs.
• The body's links both render.

I found no P1 or P2. There are two P3s. The methodology choice is the same as in round 3: the share with the lowest line 20, chosen from a candidate set.

Findings

P3-1. The premium case sets a derived variable, so its joint path leaves the premiums out

• Where: policyengine_us/tests/policy/baseline/gov/states/mt/tax/income/mt_income_tax.yaml:184, mt_eligible_medical_insurance_premiums: 3_000.
• Failure scenario: the case's household is inconsistent. mt_premium_deduction_joint reads medical_expense_health_insurance_premiums, not mt_eligible_medical_insurance_premiums. So the joint return in this household has no premiums, and its mt_income_tax_joint is 214.80, the value from the case without premiums. With the premiums, joint taxable income is 40,000 − 3 × 2,710 − (22,000 + 3,000) = 6,870, and the joint tax is 33 + 50 + 1,070 × 3% = 115.10. The case asserts only column values, so none of its assertions is wrong today. But someone extending it with mt_income_tax_joint or mt_income_tax would read off a value for a household that can't exist.
• What I ran: the same household in a Simulation, once with mt_eligible_medical_insurance_premiums: 3_000 and once with medical_expense_health_insurance_premiums: 3_000 on the head.

  derived input: share 0.655  line 1a [16375, 8625, 0]  line 20 [35.70, 35.70, 0]  mt_income_tax_joint 214.8  mt_income_tax 71.40
  raw input:     share 0.655  line 1a [16375, 8625, 0]  line 20 [35.70, 35.70, 0]  mt_income_tax_joint 115.1  mt_income_tax 71.40
                 (mt_eligible_medical_insurance_premiums [3000, 0, 0], mt_premium_deduction_joint 3000)
  

• Replacement, for a follow-up or the hub's discretion. On line 184, use medical_expense_health_insurance_premiums: 3_000, and add these to the case's output:

      mt_income_tax_joint: 115.10
      mt_files_separately: true
      mt_income_tax: 71.40

  I confirmed these values in the direct run above. I didn't run the edited YAML.

P3-2. The body still has no impact: line

• grep -n '^impact:' on the body finds nothing. The axiom: line is present (rulespec-us#1520 queued).
• Both briefs leave this line to the hub's Montana population run, but it must be added before landing.
• What can move at baseline: this round's delta is test-only and moves no output. The PR as a whole moves TY2021–2023 Montana tax units whose status 2a path is used: couples with dependents' medical bills, and status 2a couples whose itemize election flips. The population check is a Montana microsimulation for each of TY2021, 2022 and 2023, counting increases separately in 2021, where the line 20 objective can shrink the rebate. The body discloses that.

Checked and sound

• Head and range. The PR is open and not a draft, at head c08dd183f68fabaff6f73f2335420a9ba48d1d54. git log cad9f36902..c08dd183f6 shows one commit, and git diff --stat shows one file with 43 insertions.

• Recomputing the premium case, from the parameters before I read the variable's code:

  • Parameters: the 2022 exemption is 2,710 (exemptions/amount.yaml) and the floor is 7.5% (gov.irs…medical.floor). The 2022 separate schedule is 1% to 3,300 and 2% to 5,800 (main/separate.yaml).
  • Columns: with share s, the head's deduction is (25,000s − 1,875) + 3,000 and the spouse's is 25,000(1 − s) − 1,125. So their incomes before the child's exemption are 21,165 − 25,000s and 25,000s − 11,585. They are equal at s = 0.655, at 4,790 each.
  • Result: line 1a is [16,375, 8,625]. After the child's 2,710 is split, each column has 3,435 and owes 33 + 135 × 2% = 35.70, a total of 71.40.
  • The other candidates: the equal split gives 96.80, s = 1 gives 185.20, and s = 0 is higher still.
  • The code (mt_dependent_medical_expense_head_share.py:90-101) gives the same: the head's room is 1,875, kink_deduction is 0 + 3,000 of premiums, and level is 21,165.

• The minimum, checked without the model. A pure-Python search over 10,001 shares, also searching the split of the child's exemption, gives a minimum of 71.40 that is flat for shares 0.5954 to 0.7146.

  • The total doesn't pin the share, so the case is right to assert the share, line 1a and each column's line 20. All three kill M6.
  • The 0.01 margin on the share allows 0.645 to 0.665, but line 1a's 0.01 margin pins the share far more tightly.

• Mutants, each a scratch worktree, one process per file:

  Mutant	mt_income_tax.yaml	Split property file	Premium property file
  none (head)	5 passed	6 passed	5 passed
  M6: delete - kink_deduction from level	1 failed (the new case: share 0.715 vs 0.655), 4 passed	6 passed in round 3	5 passed in round 3
  M7 (mine): count premiums under the floor room in every year, dropping the if not p.state_specific_deduction_applies guard in mt_medical_floor_room	1 failed (the new case: share 0.595 vs 0.655), 4 passed	6 passed (survives)	5 passed (survives)

  • M7 by hand: the head's room is 1,875 − 3,000 = −1,125, so its level is 18,165 and s = 0.5 + 4,750 / 50,000 = 0.595. A direct run under M7 gives share 0.595, line 1a [14,875, 10,125] and line 20 [38.60, 32.90]. That is 71.50 in total, as predicted.
  • So the new case is the only test that guards the premium term in either form.
  • I removed the worktrees afterwards; git status is clean.

• The defect at main (25c4253483), TY2022: head wages $60,000, spouse $15,000, child's other medical expenses $10,250.

  • At main: mt_medical_expense_deduction_indiv [0, 0, 0], mt_tax_unit_itemizes false, mt_income_tax 2,929.68.
  • At the head: share 1.0, deduction [5,750, 0, 0] (10,250 − 7.5% × 60,000), line 20 [2,505.55, 283.75], mt_income_tax 2,789.30. These match the body's witness table.

• Overlap, with git merge-tree --write-tree --name-only:

  Pair	Result
  this head vs Use the federal itemized total and deduction type for Montana from 2024 #10206 (c1b942f276)	exit 0
  this head vs Count only filer-paid premiums in Schedule A medical expenses #10270 (2e5fccfd1f)	conflicts only in policyengine_us/tests/core/test_medical_expense_premium_conservation.py
  Count only filer-paid premiums in Schedule A medical expenses #10270 vs main (25c4253483)	the same file
  this head vs main	exit 0
  Use the federal itemized total and deduction type for Montana from 2024 #10206 vs main	exit 0
  this head vs Count a Montana casualty loss once per joint return and only for the spouse who had it #9888 (e352ed05bb)	conflicts in 16 files, including mt_itemized_deductions_indiv.py
  this head vs Cap Montana's 2021–2023 state and local tax deduction once per joint return and at $5,000 per separate column #10002 (0a4846c7b1)	conflicts in 3 files, including mt_itemized_deductions_indiv.py

  So both overlap bullets in the body hold. The search API finds no other open PR on the changed variables or files.

• The body's links. In the API's body_html, both revenuefiles.mt.gov instruction links (PDF p. 32 and p. 11) render as <a href> anchors, with no backticks in the source markdown.

• The body's round 4 claims: "M6 now fails it", the case's values, and the Count only filer-paid premiums in Schedule A medical expenses #10270 conflict "only in test_medical_expense_premium_conservation.py, as it does against main". All three match my runs.

• Readers. The delta changes no variable or parameter, so it adds no reader. The round 3 reader list stands.

• CI. The Pull request run 41861893133 at c08dd183f6 completed with success: 36 of 36 jobs succeeded, none cancelled or skipped. That covers the Baseline shards 11/11, the Contrib shards 9/9, Python Rest 9/9 plus plan and check, Microsimulation, Household API Partners, PR validation, Package and compatibility, and Quick Feedback.

• Style. ruff format --check reports "13 files already formatted" and ruff check reports "All checks passed!" on the PR's 13 Python files.

• Scope. No file is under .github/ or policyengine_us/tests/policy/baseline/partners/.

• Open since round 3, logged as follow-ups in the body: the credit-bound columns (round 3 P3-1) and the mt_files_separately strict comparison.

What I couldn't check

• Sources. This session can't reach revenuefiles.mt.gov, govinfo.gov, uscode.house.gov, ecfr.gov, rules.mt.gov or web.archive.org: the proxy answered 403, and WebFetch couldn't resolve the hosts. So I confirmed none of the legal quotes in the body: IRC 213(a), the 2021–2023 Form 2 instructions and their page numbers, ARM 42.15.524, and MCA 15-30-2132. No reading in this delta depends on them, because the delta is a test of the existing formula.
• Population impact: no microdata here (P3-2).
• Axiom: rulespec-us#1520 is outside this session's GitHub scope.
• Peak memory: /usr/bin/time isn't installed here. Wall times were 131 s for mt_income_tax.yaml, 92 s for the split property file (31.3 s pytest) and 100 s for the premium property file (40.9 s pytest), with other processes running at the same time.

---

Generated by Claude Code

[MaxGhenis]

Picking this up for the US hub. I'll post a hand-off comment here when it's ready.

---

Generated by Claude Code

[MaxGhenis]

Ready for hub review

Head: 4c615b1c7919aa7f134e85a746238c4cb1b5781e

This round builds on c08dd183f6, the head the item named. No other commit landed on the branch. I didn't merge origin/main: no check needed it.

Items

Item	Resolution
12. P3-1, the premium case's input	The case "The balancing share counts the head's medical insurance premiums" in mt_income_tax.yaml. Line 182 (the item said 184; the case starts at line 162 on this head) now sets medical_expense_health_insurance_premiums: 3_000 in place of mt_eligible_medical_insurance_premiums: 3_000. The outputs at lines 204-208 add the item's two-line comment, mt_income_tax_joint: 115.10, mt_files_separately: true and mt_income_tax: 71.40. Commit 4c615b1c79.
13. The overlap with #10038	git merge-tree --write-tree --name-only 4c615b1c79 6906894550 (#10038's head when I ran it) conflicts only in policyengine_us/variables/gov/states/mt/tax/income/deductions/itemized/general/mt_itemized_deductions_indiv.py. So I added the item's bullet verbatim after the #10206 bullet in "Overlaps with open PRs". I checked its claims first. #10038 adds "mt_misc_deductions_subject_to_floor_indiv" to that variable's add list. That variable is max_(0, pool - p.misc_floor * agi), with misc_floor 0.02 from 2017 and misc_floor_applies true only in 2017. This PR's mt_non_medical_itemized_deductions_indiv holds the list without it. #10038 has since moved to 68c2bb6cc2, a test-comment-only commit, so the conflict is unchanged.
Body	I added the #10038 bullet and a "Round 5" table (P3-1, the impact: line left for the hub, the #10038 overlap). The impact: line is still the hub's to add.
14. Runs	See below.

Tests at the head (one file per process)

File	Result
mt_income_tax.yaml	5 passed
test_mt_dependent_medical_split_invariants.py	6 passed
test_mt_medical_premium_deduction_invariants.py (the premium property file)	5 passed

No Python file changed, so ruff had nothing to check.

Mutant

Mutant	Change	Result
M6	delete - kink_deduction from level (mt_dependent_medical_expense_head_share.py:99)	Still killed. 1 failed, 4 passed: the premium case, mt_dependent_medical_expense_head_share@2022: [0.715] differs from 0.655. I restored the file afterwards.

Hand computation (TY2022 joint, from the case comment and the review)

40,000 − 3 × 2,710 = 31,870. Deductions: the child's 25,000 − 7.5% × 40,000 = 22,000 of medical, plus 3,000 of premiums, for 25,000. Taxable income is 31,870 − 25,000 = 6,870, and the tax is 33 + 50 + 1,070 × 3% = 115.10. The separate total of 71.40 is lower, so mt_files_separately is true and mt_income_tax is 71.40. The model gives the same values: the case passes.

Body links: needs the hub

The two revenuefiles.mt.gov links under "Law, and the choice it leaves" are broken again. Something on this session's outbound path rewrites those two URLs, wrapping each in backticks (](``https://revenuefiles.mt.gov/…#page=32)):``` and the #page=11one). It did this on every route I tried:gh api -X PATCH -F body=@file, a JSON --input, reference-style link definitions, and the GitHub MCP update_pull_request` tool. The file I sent has no backticks. I diffed the read-back each time, and only those two URLs were altered. Every other link and line in the body matches what I sent. Round 3's "We restored both links" suggests the same thing happened before. Please restore both links from a machine whose path doesn't rewrite them.

CI

Pull request run 41946770211 at 4c615b1c79 had not finished 60 minutes after my 01:11Z push. At 02:11Z, 34 of 36 jobs had concluded success, none had failed or been cancelled, and Contrib tests / Full Suite - Contrib (other-shard-1) and Contrib tests / Full Suite - Contrib (other-shard-3) were still in progress. Per the brief, I'm handing off with the run URL. The hub should confirm the final conclusion before landing.

The body has no CI status sentence to update. Its CI mentions are local timings.

Judgment calls

• I added a "Round 5" table to match the body's earlier rounds. It states only what this round did.
• The bullet uses the item's wording verbatim, because the merge-tree result matched the item's condition.

What I couldn't check

• The Montana instructions and IRC 213 text: I didn't fetch them. This round's change is a test input and its outputs.
• Population impact and microsimulation, per the brief.

---

Generated by Claude Code

[MaxGhenis]

Picking this up for the US hub. I'll post a hand-off comment here when it's ready.

---

Generated by Claude Code

[MaxGhenis]

Ready for hub review
96d1045

This round merges main after #10038 and carries #10038's floor deduction into the new non-medical sum. The head started at 4c615b1c79, and no one else pushed to the branch while I worked.

1. Merge of main

• 7001052730 merges main at ba9bfdea75 (newer than 7acea8ee63), with no rebase. Its parents are 4c615b1c79 and ba9bfdea75.
• The conflict. git merge-tree against ba9bfdea75 conflicts only in mt_itemized_deductions_indiv.py, as the brief predicted. I kept this PR's version unchanged: mt_itemized_deductions_indiv.py:34-35 returns mt_non_medical_itemized_deductions_indiv + head_or_spouse * medical.
• The auto-merged test. test_mt_medical_premium_deduction_invariants.py keeps both sides. I checked every line each side added against the merged file: 68 from this PR and 29 from main, none missing. Each side's removed lines are gone too.
  • This PR's side: properties 10 and 11 (docstring lines 70 and 81, checks at lines 433 and 513).
  • Main's side (Count eligible long-term care premiums in Schedule A medical expenses #10265): the long-term care variables at lines 321-322 and the property 6 subtotal at line 493.
• Main's other Montana changes since the old merge base: Count property tax and rent refunds paid outside the income tax in household and SPM benefits #10725 (property tax rebate), Model the claim of right repayment deduction and credit (26 U.S.C. 1341) and North Carolina's rules that depend on it #10038, Count eligible long-term care premiums in Schedule A medical expenses #10265 and Add state tax comparison outputs and caller documentation #10310 (rebate adjustment output). Only Model the claim of right repayment deduction and credit (26 U.S.C. 1341) and North Carolina's rules that depend on it #10038 lists itemized components.

2. The floor deduction and the component lists

• mt_non_medical_itemized_deductions_indiv.py:51 now lists mt_misc_deductions_subject_to_floor_indiv next to mt_misc_deductions, inside the head_or_spouse product, where main had it in mt_itemized_deductions_indiv (96d1045eeb).
• What I found in each file:
  • mt_itemized_deductions_joint.py:51 already lists mt_misc_deductions_subject_to_floor_joint.
  • mt_itemized_deductions_for_federal_itemization_indiv.py:51 and ..._joint.py:51 already list main's _indiv and _joint floor variables.
  • mt_dependent_medical_expense_head_share.py:67 reads mt_non_medical_itemized_deductions_indiv as other_itemized. Both the candidate taxes (line 73) and the balancing level (line 98) use it, so they now hold the floor deduction fixed.
  • tools/mt_separate_return.py builds no component list. mt_separate_tax_before_refundable_credits (line 173) takes each person's deductions as an argument.
  • mt_tax_unit_itemizes.py:42 reads mt_itemized_deductions_indiv, the non-medical sum plus the medical deduction, so the election sees the floor deduction too.
  • Outside the brief's list, _generate_state_mfs_variables.py:115 reads the mt_itemized_deductions_indiv total, which includes it.
  • Main's test_mt_mortgage_interest_federal_limit_properties.py:53-60 zeroes components to isolate mortgage interest. It runs 2021-2026, where the floor is zero, so it needs nothing.

3. The case that needs both changes

mt_income_tax.yaml:210-272, "The balancing share holds each column's miscellaneous deductions after the 2% floor fixed".

The year. TY2017 is the only year in which the code applies both paths:

• misc_floor_applies is true only in 2017. Both floor variables return 0 in any other year.
• mt_married_filing_separately_on_same_return_eligible returns married_filing_separately_on_same_return_allowed. Its first value is 2021, and core extends a first value back to earlier dates, so it is true in 2017. The case asserts [true, true, true].
• The model's Montana exemption, rate schedule and standard deduction also start in 2021, so 2017 uses the 2021 values: exemption 2,580, separate brackets 3,100 / 5,500 / 8,400 / 11,400 / 14,600 / 18,800, and cap 4,830. The case pins the model's arithmetic, not 2017 Montana law.

Inputs. Head: Montana AGI 25,000 and 2,500 of unreimbursed employee expenses. Spouse: 15,000 and 500 of tax preparation fees. Child: 25,000 of other medical expenses. mt_agi_joint is 40,000.

Hand computation, from the code before I ran the case:

Step	Arithmetic	Value
Floor deductions	2,500 − 2% × 25,000; 500 − 2% × 15,000; joint 3,000 − 2% × 40,000	2,000; 200; 2,200
Medical floors	7.5% × 25,000; 7.5% × 15,000	1,875; 1,125
Levels (level in the share variable)	25,000 − 2,580 − 2,000 − 0 + 1,875; 15,000 − 2,580 − 200 − 0 + 1,125	22,295; 13,345
Balancing share	0.5 + 8,950 / (2 × 25,000)	0.679
Line 1a	0.679 × 25,000; the rest	16,975; 8,025
Medical deduction	16,975 − 1,875; 8,025 − 1,125	15,100; 6,900
mt_itemized_deductions_indiv	2,000 + 15,100; 200 + 6,900	17,100; 7,100
Before the child's exemption	25,000 − 2,580 − 17,100; 15,000 − 2,580 − 7,100	5,320; 5,320
Taxable income	equal columns, so 2,580 is halved	4,030; 4,030
Line 20	31 + 930 × 2% each	49.60; 49.60
Equal split	itemized 12,625 and 11,575; taxable 7,215 and 845	130.45 + 8.45 = 138.90
All to the head	itemized 25,125 and 200; taxable 0 and 9,640	0 + 215.60
All to the spouse	itemized 2,000 and 24,075; taxable 17,840 and 0	640.40 + 0
Standard deductions	4,830 and 3,000; taxable 15,010 and 9,420	470.60 + 206.80 = 677.40
Joint return	40,000 − (22,000 + 2,200) − 3 × 2,580 = 8,060; 31 + 48 + 2,560 × 3%	155.80
mt_income_tax	separate 99.20 < joint 155.80	99.20

The case also asserts the floor variable, the non-medical sum, the share, line 1a, mt_tax_unit_itemizes, line 20 per column, mt_income_tax_joint and mt_files_separately. The result needs both PRs:

• Without this PR's split (main's code), the child's bills reach neither column, the couple files jointly, and the tax is 155.80.
• Without the floor variable in the list, the tax is 143.20 (below).

4. Mutant

I removed "mt_misc_deductions_subject_to_floor_indiv" from mt_non_medical_itemized_deductions_indiv.py:51 and ran mt_income_tax.yaml in its own process.

• Result: 1 failed, 5 passed. The new case fails, and no other case does. The runner stops at its first mismatch: mt_non_medical_itemized_deductions_indiv@2017: [0. 0. 0.] differs from [2000. 200. 0.].
• The headline outputs move too. A direct simulation of the same household under the mutant gives share 0.715, mt_itemized_deductions_indiv [16,000, 6,000], line 20 [71.60, 71.60] and mt_income_tax 143.20. By hand: levels 24,295 and 13,545 give s = 0.5 + 10,750 / 50,000 = 0.715. That leaves 6,420 per column before the halved exemption, so each column's 5,130 is taxed at 31 + 2,030 × 2% = 71.60.
• I restored the file and confirmed the diff against the merge commit is the one added line.

5. Tests at 96d1045eeb

One file per process.

File	Result
mt_childcare_itemization_boundary.yaml	2 passed
mt_medical_and_dental_expenses_indiv.yaml	4 passed
mt_medical_expense_deduction_indiv.yaml	13 passed
mt_tax_unit_itemizes.yaml	4 passed
mt_income_tax.yaml	6 passed
test_mt_dependent_medical_split_invariants.py	6 passed
test_mt_medical_premium_deduction_invariants.py	5 passed
Main's mt_claim_of_right_deduction.yaml	35 passed
Main's mt_taxable_income_joint.yaml	8 passed
Main's test_mt_taxable_income_properties.py	1 passed
Main's test_mt_mortgage_interest_federal_limit_properties.py	6 passed

The first runs of the two Hypothesis files stopped at collection, because my uv sync had left out the dev extra. I ran uv sync --extra dev, as CI does, and reran both. ruff format --check and ruff check pass on the changed Python file.

6. Body

I applied the update with gh api -X PATCH and read it back.

• "Changes" gains the floor variable in mt_non_medical_itemized_deductions_indiv.
• A new section, "Main merge (Model the claim of right repayment deduction and credit (26 U.S.C. 1341) and North Carolina's rules that depend on it #10038) and tests at this head", gives the merge, the new case, the mutant, the test counts and the CI line ("pending").
• "Sweep" and "Impact" now say their figures were measured before the merge at 7001052730. I left their numbers unchanged.
• "Overlaps with open PRs":
  • The Model the claim of right repayment deduction and credit (26 U.S.C. 1341) and North Carolina's rules that depend on it #10038 bullet now says it merged as 0296cdbd13 and that this merge carries its floor deduction.
  • I reran git merge-tree at the new head. Cap Montana's 2021–2023 state and local tax deduction once per joint return and at $5,000 per separate column #10002 still conflicts in 3 files and Count a Montana casualty loss once per joint return and only for the spouse who had it #9888 in 16, mt_itemized_deductions_indiv.py among them, so that bullet stands.
  • Count only filer-paid premiums in Schedule A medical expenses #10270 now conflicts in 7 files, exactly the 7 it conflicts with on main (Count eligible long-term care premiums in Schedule A medical expenses #10265 touched the same federal medical files), so this PR adds no conflict of its own. I rewrote that bullet. Use the federal itemized total and deduction type for Montana from 2024 #10206 closed without merging, so the bullet says so.
• The axiom: line and the review-round sections are unchanged.

Needs the hub: the two Form 2 instruction links in "Law, and the choice it leaves" (body lines 15-16) are broken. This session's GitHub write path wraps every mt.gov URL in backticks: I tried six forms, and every one came back wrapped. The github.com and web.archive.org links came through intact. The body at the start had the trailing half of an earlier wrap (stray backticks after both links); I removed those. Please restore both links from a local session: PDF pages 32 and 11 of the 2022 Form 2 instructions on revenuefiles. I didn't try to encode around the rewrite.

7. CI

Pull request run 42636963243 at 96d1045eeb is in progress. I didn't wait for it.

Judgment calls

• TY2017 for the new case. It is the only year in which the code applies both paths without a parameter change. The alternative is TY2022 with misc_floor_applies set true by a reform, which runs real 2022 parameters but tests a counterfactual. I chose the year the code reaches by itself and said in the case that it pins the model's arithmetic.
• The floor inputs. I used unreimbursed employee expenses and tax preparation fees, which feed Model the claim of right repayment deduction and credit (26 U.S.C. 1341) and North Carolina's rules that depend on it #10038's floor pool, rather than a claim of right repayment. That avoids a pre-2018 section 1341 calculation that Model the claim of right repayment deduction and credit (26 U.S.C. 1341) and North Carolina's rules that depend on it #10038's own 2017 cases stub out with inputs.
• The case's file. It sits in mt_income_tax.yaml beside this PR's three other status 2a cases, so the five-file list in the brief still covers it.
• Extra assertions. The case asserts the intermediate variables as well as the brief's two. So the mutant's first mismatch is the non-medical sum. The direct run above shows the headline outputs fail as well.
• Run order. Before the hand computation, I ran one feasibility simulation of a variant without the spouse's fees, to see whether 2017 computes at all. I worked the final case's values by hand before running it.
• Body scope. Beyond what the brief listed, I rewrote the Count only filer-paid premiums in Schedule A medical expenses #10270 bullet (the merge changed it) and noted that Use the federal itemized total and deduction type for Montana from 2024 #10206 closed.

Follow-up issue proposed

• Montana's 2021 parameters stand in for earlier years. The rates, exemptions, standard deduction and status 2a switch first appear in 2021, so core extends them back. Any pre-2021 Montana result, including Model the claim of right repayment deduction and credit (26 U.S.C. 1341) and North Carolina's rules that depend on it #10038's 2017 floor years, uses 2021 law unless a case supplies its own inputs.

---

Generated by Claude Code

[MaxGhenis]

David, here's where each item of your review stands at 96d1045eeb:

• Should address 1: in 8accee23e7, mt_tax_unit_itemizes makes the separate path's election by tax. When the model allows status 2a, it compares the couple's line 20 under the itemized and the standard deductions, and the summed-deduction rule decides only a tie (mt_tax_unit_itemizes.py, lines 41–55). The same commit tests it in mt_tax_unit_itemizes.yaml, and properties 2 and 3 in test_mt_dependent_medical_split_invariants.py check it for every generated couple. Your preferred fix landed in this PR, so the fallback's issue isn't needed, and the description's Readings table records my ruling on the split.
• Suggestion 1 (a tax-minimizing split): mt_dependent_medical_expense_head_share takes the share with the lowest combined line 20 among the equal split, 0, 1 and the share that balances the columns' incomes. Ties go to the share closest to the equal split (lines 54–121). I added it in 3dfd4a7333, added the balancing share in 9e2bc13d17 and dropped the floor-kink candidates in cad9f36902. Since 96d1045eeb, the balancing share also holds Model the claim of right repayment deduction and credit (26 U.S.C. 1341) and North Carolina's rules that depend on it #10038's 2% floor deduction fixed.
• Suggestion 2 (spouse_allocation_rate metadata): in 7102775bc3 and dca8b29047, its description calls the 0.5 a modeling convention, not a rate in law. Its comment contrasts ARM 42.15.524(3)(b) with (3)(c) and names all four readers. Its references cite the archived ARM text with its repeal date, the 2022 instructions p. 11 and IRS Pub. 502.
• Suggestion 3 (a downstream integration case): 8accee23e7 adds a TY2022 status 2a couple whose child's bills lower the tax (mt_income_tax.yaml, lines 41–105). It asserts the share, line 1a, mt_itemized_deductions_indiv, mt_tax_unit_itemizes, each column's line 20, mt_income_tax_joint, mt_files_separately and mt_income_tax, $2,774.63 against $2,929.68 with the standard deduction. Three more cases there cover the balancing share (lines 107–160), the head's premiums in it (lines 162–208) and Model the claim of right repayment deduction and credit (26 U.S.C. 1341) and North Carolina's rules that depend on it #10038's 2017 floor deduction (lines 210–272).
• Suggestion 4 (PR body housekeeping): the description cites no local files, and I've taken out the internal terms it still carried.

An independent AI review of these changes agreed at 96d1045eeb.

The commits since this review answer each of its items, and my reply above maps each item to its commit and file.

[MaxGhenis]

US + core hub merge audit, us#10276 at 96d1045eeb3b1f056ce9e72bdbb267f0a999f92a (squash): Count dependents' medical bills in Montana's separate-filing medical deduction.

• Reviews:
  • Independent reviews requested changes at 01fd6e5c6a (description, Axiom draft and documentation findings, fixed in b352a51acb) and on two prose claims at b352a51acb, then approved b352a51acb. Another approved a358eb61d0 with one P2: measure the split in tax.
  • DTrim99 requested changes at a358eb61d0: one should-address item (choose the itemize election by tax, or track it) and four suggestions. 8accee23e7 makes the election by tax and adds the downstream mt_income_tax case; 3dfd4a7333, 9e2bc13d17 and cad9f36902 choose the tax-minimizing share; 7102775bc3 and dca8b29047 rewrite spouse_allocation_rate's metadata.
  • An independent review requested changes at 3146e8b86f (three P2s, five P3s). Later reviews approved cad9f36902 (four P3s) and c08dd183f6 (two P3s).
  • 4c615b1c79 gives the premium case a raw premium input, 7001052730 merges main at ba9bfdea75, and 96d1045eeb carries Model the claim of right repayment deduction and credit (26 U.S.C. 1341) and North Carolina's rules that depend on it #10038's 2% floor deduction into the separate columns.
  • An independent review of the changes since c08dd183f6 agreed at 96d1045eeb. It found the merge resolution complete and recomputed all 14 new or changed expected values by hand. The description and the rulespec-us#1520 update answer three of its four P3s, and Next keeps the fourth, Montana's pre-2021 parameters.
  • I dismissed DTrim99's change request with a reply that maps each item to its commit and file.
• Gates checked live at merge:
  • gh pr checks exits 0;
  • the latest Pull request run at the head, 42773047592, passed and tested this head merged into main at 833c28bb47;
  • MERGEABLE;
  • not a draft;
  • no reviewer's latest review requests changes;
  • the semantic-overlap guard: main has changed no area this PR touches since 833c28bb47;
  • the merge pins the head.
• Impact (default dataset, 96d1045eeb against main at ba9bfdea75): we estimate that no output changes for any sampled record in 2026, and Montana income tax stays at $2.32bn. The separate path this PR changes ends after 2023. The default dataset's records start in 2024, and runs for 2021 to 2023 return $0 for every Montana total.
• Next:
  • a TY2021–2023 population estimate, which needs microdata for those years;
  • Montana's pre-2021 parameters, which the TY2017 case now takes as the 2021 values carried back;
  • a search beyond the candidate set where the capital gain credit holds a column's line 20 at zero, and mt_files_separately's strict comparison;
  • Cap Montana's 2021–2023 state and local tax deduction once per joint return and at $5,000 per separate column #10002 and Count a Montana casualty loss once per joint return and only for the spouse who had it #9888 move their changes into mt_non_medical_itemized_deductions_indiv when they next merge main.
• Axiom: TheAxiomFoundation/rulespec-us#1520 queued, now with an update for the tax-minimizing share and rows for the three TY2022 cases added since b352a51acb.

🤖 Generated with Claude Code