Add FY2025 HUD Small Area FMRs so period 2025 stops borrowing FY2026 data#8916
Merged
Merged
Conversation
The Small Area FMR CSV held FY2026 only, so `nearest_safmr_year(2025)` resolved to FY2026 — future data for a past year. Add the FY2025 SAFMR rows for the same six mandatory-SAFMR metros (Dallas, Fort Worth-Arlington, San Antonio-New Braunfels, Beaumont-Port Arthur, Kansas City KS, Wichita) so period 2025 -> FY2025 and period 2026 -> FY2026. - Extract FY2025 raw SAFMRs from HUD's published fy2025_safmrs.xlsx for the 724 ZIPs already bundled for FY2026 (retrieved 2026-07-06). 722 ZIPs are present; two (75429 Dallas, 78284 San Antonio) HUD did not publish for FY2025, so they get no FY2025 row and fall back to the county FMR at period 2025 rather than a fabricated value. FY2026 rows are unchanged. - All six metros appear on HUD's FY2025 designated-SAFMR-areas list with implementation dates of 1/1/2025 or earlier, confirming SAFMR is their HCV basis for FY2025. - Document the SAFMR file (source URLs, retrieval date, scope) in the fmr README and correct the loader docstring (six metros, not four). - Add 12 SAFMR tests exercising year-exact resolution (FY2025 differs from FY2026 for 694/722 ZIPs), the FY2025 5BR increment, nearest-year fallback at 2024/2027, and the FY2026-only ZIPs resolving to 0 at 2025. ZIP payment standards remain 2025-only (documented, not fabricated): neither TDHCA nor Houston HHA has adopted a distinct 2026 schedule as of 2026-07-06. TDHCA's latest is 2025 (no 26-HCV file); HHA's "Payment Standards for 2026" PDF is Effective 01/01/2025 with amounts identical to the bundled 2025 schedule (0 differences across 144 shared ZIPs). `nearest_payment_standard_year` therefore resolves period 2026 to the 2025 standards — an intentional forward-imputation, documented in the payment-standards README with two tests asserting the carry-forward. Addresses PolicyEngine#8801. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Makes the HUD Small Area FMR data year-accurate and documents the ZIP payment-standard year coverage, following up on the year-accuracy plan in #8801.
Before this change the SAFMR CSV held FY2026 only, so
nearest_safmr_year(2025)returned FY2026 — future data applied to a past year. This was the one actively-wrong case in #8801: atperiod 2025a Housing Choice Voucher household in a mandatory-SAFMR metro got the FY2026 SAFMR.SAFMR — FY2025 added (fixes the backward-imputation)
SAFMR 0BR…4BRcolumns from HUD's publishedfy2025_safmrs.xlsx(retrieved 2026-07-06), looked up for the exact ZIP set and metro labels already in the FY2026 CSV. Cross-validated the extraction method against the FY2026 workbook: all 3,620 existing FY2026 rows matchfy2026_safmrs.xlsxbyte-for-byte. The FY2026 block is unchanged (diff is pure insertions).period 2025they resolve to the county FMR via the existingsmall_area_fair_market_rent > 0guard inpha_payment_standard.Result:
nearest_safmr_yearZIP payment standards — 2026 intentionally forward-imputed (documented, not fabricated)
Investigated whether 2026 equivalents of the bundled 2025 PHA schedules are published. They are not, so
nearest_payment_standard_year(2026)continues to resolve to 2025 — deliberately, not as a data gap:26-HCV-PaymentStandards.pdfand variants 404).Encoding a duplicate 2026 block would fabricate a fiscal-year vintage neither PHA has published, so I left the resolver to carry the 2025 rows forward and documented the reasoning in the payment-standards README. A real 2026 block should be added once either PHA adopts new-dollar 2026 standards with a 2026 effective date.
The county FMR half of #8801 (add FY2026) already landed in #8804, so this PR closes the SAFMR gap and resolves the remaining payment-standards question by documentation.
Tests
period 2025vs2026, the FY2025 5BR increment, nearest-year fallback at 2024/2027, and the two FY2026-only ZIPs returning 0 atperiod 2025.pha_payment_standardcomments whose SAFMR references now point at the FY2025 vintage.ruff format/ruff checkclean.Sources
Addresses #8801.
🤖 Generated with Claude Code