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

Open
#493 2 comments 0 reactions 0 assignees View on GitHub

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 calibrate pass): bound anchors to the frame's design weights. Build N dense realized max ratio 5.000000000000001 — records pinned on the ceiling while net_capital_gains sat 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):

  1. 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.
  2. Record realized_max_weight_ratio_vs_design (composed) in calibration diagnostics for both arms, alongside the per-stage values.
  3. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.