Repository navigation
Certify a bundle with spm-calculator 1.1.0 and the 2022–2036 SPM forecast #618
Description
Part of the US 2036 extension, tracked in PolicyEngine/policyengine-api#3926. The canonical SPM forecast in the current bundle (6.4.0) covers 2022–2035, so every 2036 US household or economy run fails with SPM_YEAR_UNAVAILABLE. The API offers 2036 only once a bundle certifies the extended forecast.
@MaxGhenis @anth-volk, this needs a bundle certification, with these inputs:
- spm-calculator 1.1.0. Extend the canonical forecast horizon to 2036 spm-calculator#51 extends the forecast to 2022–2036 without changing any 2022–2035 value; Release spm-calculator 1.1.0 with the 2022–2036 forecast spm-calculator#52 tracks the release. Today the three extras pin
spm-calculator==1.0.0. - The new forecast digest in
src/policyengine/data/bundle/manifest.json→measurements.spm.forecast_content_sha256, which is now3d86d5c4…. It will be 1.1.0'sload_forecast().content_sha256. - A policyengine-us release that includes:
- the
spm-calculator>=1.1.0,<1.2pin, which I'll open once 1.1.0 is on PyPI; - preferably the CBO February 2026 refresh in PolicyEngine/policyengine-us, linked on #3926, so 2036 rests on CBO data rather than extrapolation.
- the
- The checks:
scripts/bundle.py certify-data,generate --include-trosandcheck --published-spm --include-tros --strict-tros. 2036 must pass and 2037 must still fail.
A question about the model gap: bundle 6.4.0 certifies policyengine-us 2.2.1, while main is on 2.4x. Does populace_us_2024 need recertifying for the newer model before the bundle moves?
The docs and tests change (2022–2036 supported, 2037 the out-of-horizon example) is a draft PR linked below. It should merge with the bundle update.
After the bundle is released, policyengine-api merges its bundle bump together with PolicyEngine/policyengine-api#3928, and policyengine-sim-api deploys the matching worker.
🤖 Generated with Claude Code
Activity
DTrim99 commentedon Nov 3, 2026
@MaxGhenis @anth-volk the inputs for this certification are all released:
335e6755dc8e0bd883e09b76c2bd53a5315683773e44d50085c7d6b8832b6291. The wheel and sdist hashes are verified against the registry and main. Inmanifest.json,measurements.spm.forecast_content_sha256moves from3d86d5c4…to this value.spm-calculator>=1.1.0,<1.2(Require spm-calculator 1.1 for the 2022–2036 SPM forecast policyengine-us#10620). It includes the CBO February 2026 refresh (Load CBO's February 2026 projections through 2036 into the upraters policyengine-us#10227) and the follow-ups (Uprate poverty guidelines over the 9902(2) interval and fix the Trustees wage base policyengine-us#10453). A clean install calculates 2036 SPM thresholds and refuses 2037.spm.pymove to335e6755…along with the bundle, as Pavel noted on Extend the canonical forecast horizon to 2036 spm-calculator#51.populace_us_2024need recertifying for 2.94.0 before the bundle moves?supported_yearsshould then report US 2036.DTrim99 commentedon Nov 10, 2026
@MaxGhenis @anth-volk For the 2036 bundle: the national release
populace-us-2024-spm-20260915already claimspolicyengine-us >=2.0.0,<2.3, so it covers 2.2.2. The ACS-local releasepopulace-us-2024-buildo-acs-local-766b7c7-20261017T030317Zwas built with 2.2.1 and has nocompatible_model_packagesclaim, socertify-datawill refuse it for 2.2.2.Could one of you publish a claim on that manifest for
policyengine-us >=2.2.1,<2.3, the same kind as the national one? The reasoning holds the same way. policyengine-us 2.2.2, released 2026-11-09 from PolicyEngine/policyengine-us#10765, is 2.2.1 plus the spm-calculator 1.1 pin and CBO's 2036 CPI-U points. It has no variable, input or loader changes, so the H5 reads identically.Once the claim is up, I'll run
set-spmandcertify-datafor policyengine-us 2.2.2 + spm-calculator 1.1.0 and open the .py PR.