Skip to content

Decide ConnectorCare's ceiling and Plan Type bands on the exact FPL ratio - #10321

Draft
MaxGhenis wants to merge 1 commit into
mainfrom
ma-connectorcare-exact-fpl-ratio
Draft

MaxGhenis wants to merge 1 commit into
mainfrom
ma-connectorcare-exact-fpl-ratio

Conversation

@MaxGhenis

@MaxGhenis MaxGhenis commented Oct 20, 2026 •

Copy link
Copy Markdown
Contributor

Draft. Done: the fix and YAML cases. Pending: full-file impact, Axiom parity line, GPT-6.1 Sol review.

Bug

ConnectorCare compared the truncated aca_magi_fraction (np.floor(100 * magi / fpg) / 100) with income edges in two places:

  1. Plan Type bands (ma_connector_care): enrollee_premium.calc(aca_magi_fraction) with thresholds 1.5001, 2.0001, 2.5001 and 3.0001. 956 CMR 12.04(3)(b) puts persons "at or below 150% of FPL" in Plan Type 2A and "those over 150% and not over 200% of FPL" in 2B; 3A, 3B and 3C follow the same "above X% ... and not over Y%" form. Truncation maps 150.00%-150.99% to 1.50, so all of it priced as 2A ($0 a month) instead of 2B ($53); likewise above 200%, 250% and 300%.
  2. The 400% ceiling (ma_connector_care_eligible, <= 4.0): 3C is "not over 400% of the FPL", and truncation admitted up to 400.99%. Members must be is_aca_ptc_eligible, whose income test ends at 400% from 2026, so this ceiling decides alone only under a reform that extends the federal credit.

No source prescribes truncating the percentage; the Overview's "150.1%" labels describe the bands, not a rounding rule. The 100% floor ("at least 100%") is unaffected by truncation.

Executed on main (645fcd3; the files are unchanged at 740e1eb), single member in Massachusetts, 2026, 2025 one-person guideline $15,650:

Income Exact % of FPL aca_magi_fraction Main Here
$23,475 150.000% 1.50 2A, $0/mo 2A, $0/mo
$23,475.47 150.003% 1.50 2A, $0/mo 2B, $53/mo
$23,630.56 150.994% 1.50 2A, $0/mo 2B, $53/mo
$31,300.47 200.003% 2.00 2B 3A
$39,125.47 250.003% 2.50 3A 3B
$46,950.47 300.003% 3.00 3B 3C
$62,600.47 400.003% 4.00 eligible (gate alone) ineligible

Fix

  • Both read the exact ratio max(aca_magi, 0) / tax_unit_fpg(period.last_year), the pattern of Decide California Premium Subsidy eligibility on the exact FPL ratio #10305.
  • enrollee_premium thresholds become the band edges (1.5, 2, 2.5, 3), and ma_connector_care evaluates the scale right-closed, so income exactly at an edge stays in the band below (as 956 CMR's "not over" requires) and any income above it moves up. The parameter comments describe the new convention.

Invariants

For every input, with the program in effect and an APTC-eligible member, r = max(MAGI, 0) / FPG(prior year):

  1. Eligibility = regulation. Eligible if and only if 1 <= r <= 4.
  2. Bands = regulation. Plan Type 2A for r <= 1.5, 2B for 1.5 < r <= 2, 3A for 2 < r <= 2.5, 3B for 2.5 < r <= 3, 3C for 3 < r <= 4.
  3. Monotone in income. The per-person premium never falls as r rises (each band's amount exceeds the one below).
  4. Only slivers change. Relative to main, results differ only for r in (1.5, 1.51), (2, 2.01), (2.5, 2.51), (3, 3.01) and (4, 4.01). In the first four the enrollee premium rises a band, so ma_connector_care can only fall. The last is federally ineligible under current law.

No Hypothesis test is added: the YAML cases hit every band edge exactly and 0.003 points above it with the real guideline, and the existing cases cover each band's interior. The repo's test-design rules keep such cases in YAML.

Tests

  • Every case in the three ConnectorCare YAML files that supplied aca_magi_fraction now supplies aca_magi against a prior-year tax_unit_fpg of $10,000, so it still drives the gate and the band.
  • ma_connector_care.yaml Cases 24-32: the real guideline at 150%, 150.003%, 150.994%, 200%, 200.003%, 250%, 250.003%, 300% and 300.003%, with the expected Plan Type and subsidy. The existing exactly-at-edge cases (6, 8, 10, 12) still land in the lower band.
  • ma_connector_care_eligible.yaml Cases 9-12: $62,600 eligible; $62,600.47 and $62,755.56 ineligible; Case 12 sets gov.aca.ptc_income_eligibility[2].amount: true, so at $62,600.47 the member is federally eligible and the ConnectorCare ceiling decides.
  • Mutation check: main's variables and parameter fail exactly the eight new above-edge cases.
  • Local differential sweep (a script, not committed, per the repo's test-design rules): 256 tax units per year, 60% with income in cents within $2 of an edge and the rest uniform, guidelines $10,000-$80,000 including $20 multiples, comparing the eligibility gate with an exact-rational reading of the source on the float32 values the model receives. 0 mismatches here; on main the same draws give 44 mismatches, all in the truncation sliver.
  • Local run: the ConnectorCare YAML folder, 56 passed.

Impact

Pending: full-file microsimulation via the US hub impact queue, 2026 and 2027.

Coordination

#10041 (draft) edits ma_connector_care.yaml and ma_connector_care_member_eligible.yaml and changes aca_magi_fraction's denominator to a new aca_fpg; if it lands, these exact ratios should use the same denominator. Part of the aca_magi_fraction audit (table: #10329) begun with #10305; federal edge in #10312.

axiom: pending

🤖 Generated with Claude Code

…atio

956 CMR 12.04(3)(b) assigns Plan Types by household income: "at or below
150%" (2A), "over 150% and not over 200%" (2B), "above 300% ... and not
over 400%" (3C). ConnectorCare compared the truncated aca_magi_fraction
with these edges, so incomes from 150.00% to 150.99% landed in 2A (and the
same slivers above 200%, 250% and 300% in the band below), and the 400%
gate admitted up to 400.99%. Use the exact ratio of nonnegative ACA MAGI
to the prior-year guideline for both, and evaluate the enrollee-premium
scale right-closed with thresholds at the band edges, so income exactly at
an edge stays in the lower band.

Tests that supplied aca_magi_fraction now supply aca_magi against a
prior-year guideline of $10,000; new cases use the real 2025 guideline at
each band edge and at 400%.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant