PolicyEngine / PolicyEngine/microcosm
max_weight_ratio anchors differently per arm: 5x vs design (dense) but ~25x effective (sparse refit re-anchors) — declare one stretch contract
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 0
- Forks
- 4
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 94
Description
max_weight_ratio (default 5.0) is documented as the hard per-record guard: no calibrated weight may exceed 5 × initial_weight (solve.py:27). But the bound's anchor differs by arm:
- Dense (single
calibratepass): bound anchors to the frame's design weights. Build N dense realized max ratio 5.000000000000001 — records pinned on the ceiling whilenet_capital_gainssat at −30.2% ($887.0B vs the truthful $1,270.9B target). - Sparse (
calibrate_l0_refit): the refit "calls calibrate again" on the selection's frame, and "the refit's starting weights are the selection stage's calibrated weights" (refit_l0_selection docstring). The 5× bound therefore re-anchors: each stage individually ≤5×, composed vs design ≤ ~25×. Published N sparse refit realized 4.99 on top of its selection anchor and reaches the same CG target at −2.4%.
So the shipped-artifact contract "weights stay within R× of the design prior" is currently an emergent accident: R=5 for dense, R≈25 for sparse — never adjudicated, and invisible in any manifest (each stage records only its own realized ratio).
Ask (ties to the #492 discussion of principled-calibration contracts):
- Decide the intended contract: one declared stretch envelope vs the record's design/prior weight for the SHIPPED weights, identical semantics across arms — either the refit inherits the design anchor (composed bound stays 5× vs design) or the two-stage envelope is explicitly declared and recorded.
- Record
realized_max_weight_ratio_vs_design(composed) in calibration diagnostics for both arms, alongside the per-stage values. - Note the interaction with dense-vs-sparse evidence claims: dense's CG depth failure is currently evidence about the base under a 5× envelope, while sparse's success is under ~25× — cross-arm comparisons should say so.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with packages/populace-calibrate/src/populace/calibrate/solve.py:27 and the refit_l0_selection docstring to trace how each stage anchors weights. Compare the dense and sparse diagnostics, then define and document one cross-arm stretch contract. Done means the shipped weights use the declared anchor and both arms record realized_max_weight_ratio_vs_design alongside per-stage ratios.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- data
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100